cited surjection... whoopy doop

mybib.bib

@@ -1,5 +1,12 @@
 
 
+@BOOK{dmfnt,
+  AUTHOR =       "R Garnier, J Taylor",
+  TITLE =        "Discrte Mathematics for New Technology ISBN 0-7503-0135-X",
+  PUBLISHER =      "IoP",
+  YEAR =         "1992"
+}
+
 @ARTICLE{embedsfmea,
   AUTHOR =       "Peter L. Goddard",
   TITLE =        "Validating The Safety of Embedded Real-Time Control Systems using FMEA",

papers/fmea_software_hardware/Makefile

@@ -8,7 +8,7 @@ PNG = fmmdh.png ct1.png hd.png ftcontext.png
 all: ${PNG}
 	pdflatex software_fmea
 	pdflatex software_fmea
-	acroread software_fmea.pdf
+	acroread software_fmea.pdf || okular software_fmea.pdf
 
 bib:
 	bibtex software_fmea
@@ -21,4 +21,4 @@ abs:	# bib
 	cat abs_end.tex >> abstract.tex	
 	# bib abs.tex
 	pdflatex abstract
-	acroread abstract.pdf
+	acroread abstract.pdf || okular abstratc.pdf

papers/fmea_software_hardware/mybib.bib

@@ -1 +0,0 @@
-../../mybib.bib

papers/fmea_software_hardware/software_fmea.tex

@@ -172,7 +172,7 @@ This is associated with Safety Integrity Levels (SIL)~\cite{en61508}~\cite{en615
 FMMD is a modularisation of FMEA and can produce failure~mode models that can be used in
 all the above variants of FMEA. 
 
-\subsection{Current work on Software FMEA}
+\subsection{Current work on Software FMEA.}
 
 Work on  SFMEA usually does not seek to integrate
 hardware and software models, but to perform
@@ -181,15 +181,19 @@ Some work has been performed using databases
 to track the relationships between variables 
 and system failure modes~\cite{procsfmeadb}, and work has been performed to 
 introduce automation into the FMEA process~\cite{appswfmea} and code analysis
-automation~\cite{modelsfmea}. Although the SFMEA and hardware FMEAs are performed separately
+automation~\cite{modelsfmea}. Performing these analyses separate breaks the reasoning chain for tracing 
+failure causation through the software hardware interfaces.
+
+Although the SFMEA and hardware FMEAs are performed separately
 some schools of thought aim for FTA~\cite{nasafta}~\cite{nucfta} (top down - deductive) and FMEA (bottom-up inductive)
 to be performed on the same system to provide insight into the
-software hardware/interface~\cite{embedsfmea}, although this
+software hardware/interface~\cite{embedsfmea}. 
+Although this
 would give a better picture of the failure mode behaviour, it
 is by no means a rigorous approach to tracing errors that may occur in hardware
-through the top (and therfore untimately controlling) layer of software.
+through to the top (and therefore ultimately controlling) layer of software.
 
-\subsection{Current FMEA techniques are not suitable for software}
+\subsection{Current FMEA techniques are not suitable for software.}
 
 The main FMEA methodologies are all based on the concept of taking  
 base component {\fms}, and translating them into system level events/failures~\cite{sfmea}~\cite{sfmeaa}.
@@ -947,7 +951,7 @@ of this paper.
 { %\tiny %
 \footnotesize
 \bibliographystyle{plain}
-\bibliography{vmgbibliography,mybib}
+\bibliography{../..vmgbibliography,../..mybib}
 }
 
 %\today

papers/fmea_software_hardware/vmgbibliography.bib

@@ -1 +0,0 @@
-../../vmgbibliography.bib

papers/fmmd_software_hardware/Makefile

@@ -8,7 +8,7 @@ PNG = fmmdh.png ct1.png hd.png ftcontext.png
 all: ${PNG} bib
 	pdflatex software_fmmd
 	pdflatex software_fmmd
-	acroread software_fmmd.pdf
+	acroread software_fmmd.pdf || okular software_fmmd.pdf
 
 bib:
 	bibtex software_fmmd
@@ -20,4 +20,4 @@ abs:    # bib
 	cat abs.tex >> abstract.tex
 	cat abs_end.tex >> abstract.tex
 	pdflatex abstract
-	acroread abstract.pdf
+	acroread abstract.pdf || okular abstract.pdf

papers/fmmd_software_hardware/mybib.bib

@@ -1 +0,0 @@
-../../mybib.bib

papers/fmmd_software_hardware/software_fmmd.tex

@@ -1040,7 +1040,7 @@ of this paper.
 { %\tiny %
 \footnotesize
 \bibliographystyle{plain}
-\bibliography{vmgbibliography,mybib}
+\bibliography{../../vmgbibliography,../../mybib}
 }
 
 %\today

papers/fmmd_software_hardware/vmgbibliography.bib

@@ -1 +0,0 @@
-../../vmgbibliography.bib

submission_thesis/CH4_FMMD/copy.tex

@@ -2,21 +2,21 @@
 %% CHAPTER 4 : Failure Mode Modular Discrimination
 %%
 
-\ifthenelse {\boolean{paper}}
+% \ifthenelse {\boolean{paper}}
-{
+% {
-\abstract{ 
+% \abstract{ 
-This paper defines %what is meant by 
+% This paper defines %what is meant by 
-the terms
+% the terms
-components, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes.
+% components, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes.
-%The application of Bayes theorem  in current methodologies, and
+% %The application of Bayes theorem  in current methodologies, and
-%the suitability of the `null hypothesis' or `P' value statistical approach
+% %the suitability of the `null hypothesis' or `P' value statistical approach
-%are discussed.
+% %are discussed.
-The general concept of the cardinality constrained powerset is introduced
+% The general concept of the cardinality constrained powerset is introduced
-and calculations for it described, and then for
+% and calculations for it described, and then for
-calculations under `unitary state' fault mode conditions.
+% calculations under `unitary state' fault mode conditions.
-Data types and their relationships are described using UML.
+% Data types and their relationships are described using UML.
-Mathematical constraints and definitions are made using set theory.}
+% Mathematical constraints and definitions are made using set theory.}
-}
+% }
 {
 \section{Overview}
 This chapter defines the FMMD process and related concepts and calculations.
@@ -28,6 +28,14 @@ These {\dcs} are used to then build further {\fgs} until a hierarchy of {\fgs}
 and {\dcs} has been built, converging to a final {\dc}
 at the top of the hierarchy.
 
+Or in other words we take the traditional FMEA process, and modularise it.
+We break down each stage of reasoning
+into small manageable groups, and use the results of those groups, as {\dcs}
+to build higher level groups. 
+%This has advantages of concentrating
+%effort in where modules interact, 
+
+  
 %% J. Howse 04MAY2012 REMOVEFirstly, %what is meant by 
 %% J. Howse 04MAY2012 REMOVEthe terms
 %% J. Howse 04MAY2012 REMOVEcomponents, failure~modes, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes are defined.
@@ -51,12 +59,369 @@ paper
 {
 chapter 
 }
-starts with a worked example using the new methodology, Failure Mode Modular De-composition (FMMD), and then
+starts with a worked example using the new methodology, Failure Mode Modular De-composition (FMMD).
-develops an ontological structure for the methodology using UML class models.
+This is followed by a discussion on the design of the FMMD methodology and then
-A  notation is then described to index and classify objects created in FMMD models.
+an ontological description is given using UML class models.
+A  notation is then described to index and classify objects created in FMMD hierarchical models.
+
+
+We briefly analyse four current methodologies.
+Comprehensive overviews of these methodologies may be found
+in ~\cite{safeware,sccs}. 
+
+\paragraph{Fault Tree Analysis (FTA).}
+FTA~\cite{nasafta,nucfta} is a top down methodology in which a hierarchical diagram is drawn for
+each undesirable top level failure/event, presenting the conditions that must arise to cause
+the event. 
+%
+It is suitable for large complicated systems with few undesirable top
+level failures and focuses on those events considered most important or most catastrophic.
+%
+Effects of duplication/redundancy of safety systems can be readily assessed. 
+It uses notations that are readily understood by engineers 
+(logic symbols borrowed from digital electronics and a fault hierarchy). 
+However, it cannot guarantee to model all base component failures 
+or be used to determine system level errors other than those modelled. 
+%
+Each FTA diagram models one top level event.
+This creates duplication of modelled elements, 
+and it is difficult to cross check between diagrams. It has limited 
+support for environmental and operational states.
+
+
+\paragraph{Fault Mode Effects Analysis (FMEA)} is used principally to determine system reliability. 
+It is bottom-up and starts with component failure modes, which
+lead to top level failure/events.
+Each top level failure is assessed by its cost to repair (or perceived criticality) and its estimated frequency. %, using a 
+%failure mode ratio. 
+A list of failures according to their cost to repair~\cite{bfmea}, or effect on system reliability is then calculated. 
+It is easy to identify single component failure to system failure mappings 
+and an estimate of product reliability can be calculated. 
+%This can be viewed as a prioritised `to~fix' list.
+%
+It cannot focus on complex
+component interactions that cause system failure modes or determine potential 
+problems from simultaneous failures. It does not consider changing environmental 
+or operational states in sub-systems or components. It cannot model 
+self-checking safety elements or other in-built safety features or 
+analyse how particular components may fail.
+
+
+\paragraph{Failure Mode Effects Criticality Analysis (FMECA)} is a refinement of FMEA, using 
+extra variables: the probability of a component failure mode occurring,
+the probability that this will cause a given  top level failure, and the perceived 
+criticality. It gives better estimations of product reliability/safety and the 
+occurrence of particular system failure modes than FMEA but has similar deficiencies.
+
+
+\paragraph{Failure Modes, Effects and Diagnostic Analysis (FMEDA)} is a refinement of 
+FMEA and FMECA and in addition models self-checking safety elements. It assigns two 
+attributes to component failure modes: detectable/undetectable and safe/dangerous.
+ Statistical measures about the system can be made and used to classify a 
+safety integrity level. It allows designs with in-built safety features to be assessed. 
+Otherwise, it has similar deficiencies to FMEA.
+However, it has limited support 
+for environmental and operational states in sub-systems or components, 
+via self checking statistical mitigation. FMEDA is the methodology associated with 
+the safety integrity standard EN61508~\cite{en61508}.
+
+\subsection{Summary of Deficiencies in Current Methods}
+
+\paragraph{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component
+level failure modes~\cite{faa}[Ch.9]. Since one FTA tree is drawn for each top level
+event, this leads to repeated work, with limited ability for cross checking/model validation.
+Also, the analysis process can miss top level events that bottom-up techniques
+can reveal.
+
+%\subsection{Bottom-up approach: }
+
+\paragraph{State Explosion problem for FMEA, FMECA, FMEDA.}
+The bottom-up techniques all suffer from % a problem of 
+state explosion.
+To perform the analysis rigorously, we would need to consider the effect
+of a component failure against all other components. Adding environmental
+and operational states further increases the state explosion.
+
+Let $N$ be the number of components in our system, and $K$ be the average number of component failure modes
+(ways in which a component can fail). The approximate total number of base component failure modes
+is $N \times K$. 
+%
+The total number of cases to examine, to determine the effect of all failure modes 
+on all 
+components 
+will be approximately $(N-1) \times N \times K$. %, in effect a very large set cross product.
+%
+If $E$ is the number of environmental conditions to consider
+in a system, and $A$ the number of applied/operational states (or modes of the system),
+the bottom-up analyst is presented with two
+additional %cross product 
+factors, yielding approximately
+$(N-1) \times N \times K \times E \times A$.
+%
+If we put some typical very small embedded system numbers\footnote{These figures would
+be typical of a very simple temperature controller, with a micro-controller, sensors, an RS485 interface,
+supporting circuitry and heater circuitry.}
+ into this, say $N=100$, $K=2.5$, $A=2$, and $E=10$
+we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $ checks to perform.
+%
+To look in detail at half a million fault~scenarios is obviously impractical.
+
+
+% Requirements for an improved methodology The deficiencies identified in the 
+% current methodologies are used to establish criteria for an improved methodology.
+
+\paragraph{Reasoning distance - complexity and reach-ability.}
+Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
+working heuristically. A base component failure will typically 
+be conceptually removed by several stages from a top level event.
+The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
+that must interact to reach the top level event.
+Where $C$ represents the set of components in a failure mode causation chain,
+$c_i$ represents a component in $C$ and
+the function $fm$ returns the  failure modes for a given component, equation
+\ref{eqn:complexity}, returns the `reasoning~distance'.
+\begin{equation}
+R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
+\label{eqn:complexity} 
+\end{equation}
+%
+The reasoning distance is a value representing the number of failure modes
+to consider to rigorously determine the causation chain
+from the base component failure to the system level event.
+%
+The reasoning distance serves to show that when the causes of a top level
+event are completely determined, a large amount of work not
+typical of heuristic or intuitive interpretation is required.
+% could have a chapter on this.
+% take a circuit or system and follow all the interactions
+% to the components that cause the system level event.
+
+\paragraph{Multiple Events from one base component failure mode.}
+A base component failure may potentially cause more than one
+system level failure mode.
+It could be possible to identify one top level event associated with
+a {\bc} {\fm} and not investigate other possibilities, using FMEA or FTA techniques. 
+ 
+ 
+\paragraph{Software FMEA models are performed separately from Hardware FMEA.}
+%If software FMEA or Software FTA is performed it is always performed separately from
+%hardware FMEA.
+Work on  SFMEA (where it is actually performed) does not seek to integrate
+hardware and software models, but to perform
+FMEA on the software in isolation~\cite{procsfmea}.
+Some work has been performed using databases
+to track the relationships between variables 
+and system failure modes~\cite{procsfmeadb}, and work has been performed to 
+introduce automation into the FMEA process~\cite{appswfmea} and code analysis
+automation~\cite{modelsfmea}. Performing these analyses separate breaks the reasoning chain for tracing 
+failure causation through the software hardware interfaces.
+
+Although the SFMEA and hardware FMEAs are performed separately
+some schools of thought aim for FTA~\cite{nasafta}~\cite{nucfta} (top down - deductive) and FMEA (bottom-up inductive)
+to be performed on the same system to provide insight into the
+software hardware/interface~\cite{embedsfmea}. 
+Although this
+would give a better picture of the failure mode behaviour, it
+is by no means a rigorous approach to tracing errors that may occur in hardware
+through to the top (and therefore ultimately controlling) layer of software.
+%\section{Requirements for a new static failure mode Analysis methodology}
+
+\section{Desirable Criteria.}
+From the deficiencies outlined above,  we can form a set of desirable criteria for an enhanced failure mode methodology.
+{ %\small
+\label{criteria}
+\begin{enumerate}
+%\begin{itemize}
+\label{fmmdreq}
+\item Address the state explosion problem. % 1
+\item Ensure that all component failure modes are considered in the model. % 2
+\item Be easy to integrate mechanical, electronic and software models \cite{sccs}[p.287]. %3
+\item Be modular, in that commonly used {\fgs} can be re-used in other designs/projects. %4
+\item Have a formal basis, i.e. be able to produce mathematical traceability %5
+for its results, such as  error causation trees.%, reliability and safety statistics.
+%\item It should be easy to use, ideally using a 
+%graphical syntax (as opposed to a formal symbolic/mathematical text based language).
+%\item From the top down, the FMMD model of a system, should follow a logical de-composition of the functionality
+%to smaller and smaller functional groupings--or--modules. \cite{maikowski}.
+\item Be able to model multiple (simultaneous) failure modes.% 6 % from the base component level up.
+\end{enumerate}
+%\end{itemize}
+}
+
+
+% 
+
+% The design process follows this 
+%rationale, sub-systems are build t%o perform often basic functions from base components.
+%We can term these small groups {\fgs}.
+% 
+% Components should be collected
+% into small functional groups to enable the examination of the effect of a
+% component failure mode on the other components in the group.
+% Once we have the failure modes, or symptoms of failure of a {\fg}
+% it can now be considered as `derived component' with a known set 
+% of failure symptoms. We can use this `derived component' to build higher level 
+% functional groups.
+% 
+% This helps with the reasoning distance problem,
+% because we can trace failure modes back through complex interactions and have a structure to
+% base our reasoning on, at each stage.
+% 
+
+
+%Development of the new methodology 
+% 
+% \section{An ontology of failure modes}
+% In order to address the state explosion problem, the process must be modular
+%and deal with small groups of components at a time. This approach should address the state explosion problem : criteria 1.
+% An ontology is now developed of  
+% failure modes and their relationship to environmental factors, 
+% applied/operational states and the hierarchical nature inherent in product design, 
+% defining the relationships between the system as a whole, components, 
+% failure modes, operational and environmental states. 
+% 
+% 
+% Components have sets of failure modes associated with them.
+% Failure modes for common components may be found in 
+% the literature~\cite{fmd91,mil1991}.
+% We can associate a component with its failure modes.
+% This is represented in UML in figure \ref{fig:component_concept}.
+% 
+% \begin{figure}[h]
+%  \centering
+%  \includegraphics[width=200pt,keepaspectratio=true]{./component.png}
+%  % component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76
+%  \caption{Component with failure modes UML diagram}
+%  \label{fig:component_concept}
+% \end{figure}
+
+% 
+% \subsection{Modular Design}
+% 
+% When designing a system from the bottom-up, small groups of components are selected to perform
+% simple functions. These can be termed {\fgs}.
+% When the failure mode behaviour, or symptoms of failure 
+% of a {\fg} are determined, it can be treated as a component in its own right.
+% 
+% % Functional groups
+% % are then brought together to form more complex and higher level {\fgs}.
+% Used in this way the {\fg} has become a {\dc}. The symptoms of failure
+% of the {\fg} can be considered the failure modes of its {\dc}.
+% Derived~Components can be used to create higher level {\fgs}.
+% Repeating this process will lead to identify-able higher level
+% groups, often referred to as sub-systems. We can call the entire collection/hierarchy
+% of sub-systems the system. 
 
 
 
+\section{The proposed Methodology}
+\label{fmmdproc}
+% Any new static failure mode methodology must ensure that it 
+% represents all component failure modes and it therefore should be bottom-up, 
+% starting with individual component failure modes.
+To ensure all component failure modes are represented, the new methodology must be bottom-up.
+%
+This seems essential to satisfy criterion 2.
+The proposed methodology is therefore a bottom-up process
+starting with base~components.
+%
+Since we are only modelling failure modes, which could arise from
+mechanical, electronic or software components,
+criterion 3 is satisfied.
+%
+In order to address the state explosion problem, the process should be modular and hierarchical,
+dealing with small groups of components at a time; this should address criterion 1.
+
+
+%\paragraph{Outline of the Failure mode methodology.}
+%
+A {\em {\fg}}, is defined as a small collection of components
+that interact to provide
+a function or task within a system.
+%
+In the proposed methodology components are collected into functional groups
+and each component failure (and possibly multiple simultaneous component failures) are considered in the 
+context of the {\fg}.
+
+%% GARK
+%
+The component failures are termed {\em{\fcs}}. %`test~cases'. 
+For each {\fc}
+there will be a corresponding resultant failure, or `symptom', from the perspective of the {\fg}.
+%
+% MAYBE NEED TO DESCRIBE WHAT A SYMPTOM IS HERE
+%
+%From the perspective of the {\fg} failures of components will be symptoms.
+It is conjectured that many symptoms will be common. That is to say
+that component failures will often cause the same symptoms of failure
+from the perspective of a {\fg}.
+
+
+
+%
+A common symptom collection stage is now applied. Here common symptoms are collected
+from the results of the {\fcs}. Because it is possible to model combinations of failures,
+criterion 6 is satisfied.
+%
+With a collection of the {\fg} failure symptoms, we can create a {\em{\dc}}.
+The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from.
+This satisfies criterion 4, as we can now treat {\dcs} as pre-analysed
+modules available for re-use.
+ 
+By using {\dcs} in higher level functional groups, a hierarchy can be built representing
+the failure mode behaviour of a system. Because the hierarchy maintains information 
+linking the symptoms  to component failure modes (via {\fcs}), we have traceable
+reasoning connections from base component failures to top level failures.
+The traceability should satisfy criterion 5.
+
+%  ONTOLOGY - NO ROOM IN 6 PAGES OF PAPER
+% \paragraph{Environmental Conditions, Operational States.}
+% 
+% Any real world sub-system will exist in a variable environment
+% and may have several modes of operation.
+% In order to find all possible failures, a sub-system 
+% must be analysed for each operational state
+% and environmental condition that could affect it.
+% %
+% A question is raised here: which objects should we 
+% associate  the environmental and the operational states with ?
+% There are three objects in our model to which these considerations could be applied.
+% We could apply these conditions  
+% to {\fgs}, components, or {\dcs}.
+% 
+% \paragraph {Environmental Conditions.}
+% 
+% Environmental conditions are external to the
+% {\fg} and are often things over which the system has no direct control
+% ( e.g. ambient temperature, pressure or  electrical interference levels).
+% %
+% Environmental conditions may affect different components in a {\fg}
+% in different ways.
+% 
+% For instance, a system may be specified for
+% $0\oc$  to $85\oc$ operation, but some components
+% may show failure behaviour between $60\oc$  and $85\oc$ 
+% \footnote{Opto-isolators typically show marked performance decrease after
+% $60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
+% Other components may operate comfortably within that whole temperature range specified.
+% Environmental conditions will have an effect on the {\fg} and the {\dc},
+% but they will have specific effects on individual components.
+% 
+% It seems obvious that
+% environmental conditions should apply to components.
+% %A component will hold a set of environmental states that
+% %affect it. 
+% 
+% \paragraph {Operational States}
+% 
+% Sub-systems may have specific operational states.
+% These could be a general health level, such as 
+% normal operation, graceful degradation or lockout.
+% Alternatively they could be self~checking sub-systems that are either in a normal, alarm/lockout or self~check state.
+% 
+% Operational states are conditions that apply to some functional groups, not individual components.
+
+%\section{The Non-Inverting Operational Amplifier}
 %When this constraint is complied with, we can use the FMMD method to 
 %build hierarchical bottom-up models of failure mode behaviour.
 %This and the definition of a component are 
@@ -555,9 +920,11 @@ of component failures.
 
 \section{Defining terms}
 
+The worked example used terms such as {\fg}, component, and {\dc}.
+This chapter aims to define these terms.
 
 
-
+\subsection{Parts, components and base components}
 A component is anything we use to build a product or system. 
 It could be something quite complicated 
 like an integrated micro controller, or quite simple like the humble resistor.
@@ -581,7 +948,8 @@ We define {\bc} to mean a lowest level of assembly `part' or an atomic entity, w
 and component to mean either a part or a sub-assembly. 
 Definitions used in FMMD are listed in table~\ref{tbl:fmmd_defs} and discussed below.
 
-%%  
+%%  FUCKING STEREO SUB_SYSTEM EXAMPLE, THE FUCKING CHILDRENS SECTION
+
 \subsection{Systems, functional groups, sub-systems and failure modes: sound system example}
 
 It is helpful here to define the terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'.
@@ -589,6 +957,8 @@ It is helpful here to define the terms, `system', `functional~group', `component
 
 A system, is any coherent entity that would be sold as a product. % safety critical product.
 A sub-system is a system that is part of some larger system.
+A modular system common in most homes is the sound separates audio system or stereo hi-fi.
+This is now used as an example to describe terms used in FMMD.
 For instance a stereo amplifier separate/slave is a sub-system. The 
 whole sound system, consists perhaps of the following `sub-systems': 
 CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
@@ -1047,8 +1417,8 @@ Operational states and environmental conditions must be factored into the UML mo
 levels of electrical interference, high voltage contamination on supply
 lines, radiation levels etc.
 Environmental influences will affect specific components in specific ways.\footnote{A good example of a part 
-affected by environmental conditions, in this case temperature, is the opto-isolator
+affected by environmental conditions, in this case temperature, is the opto-isolator~\cite{tlp181}
-which is typically affected at around \oc{60}. Most electrical components are far more robust to temperature.~\cite{tlp181}.}.
+which is typically affected at around \oc{60}. Most electrical components are far more robust to temperature.}.
 Environmental analysis is thus applicable to components.
 Environmental influences, such as over stress due to voltage
 can be eliminated by down-rating of components as discussed in section~\ref{sec:determine_fms}.
@@ -1193,7 +1563,7 @@ in sections~\ref{sec:formalfmmd} and \ref{algotithmfmmd} respectively.
 
 
 \paragraph{Surjective constraint applied to symptom collection.}
-We can stipulate that symptom collection process is surjective.
+We can stipulate that symptom collection process is surjective~\cite{dmfnt}.
 % i.e. $ \forall f in F $ 
 By stipulating surjection for symptom collection, we ensure
 that each component failure mode maps to at least one symptom.
@@ -1224,7 +1594,7 @@ are always orders of magnitude smaller than sum of {\fms} in its base components
 Integrated components such as OP-AMPS are already treated as {\dcs}
 in literature.
 An Op-AMP is an integrated circuit comprising some hundred or so individual components
-but in the literature ~\cite{fmd91} is is described as a simple component with a set of failure modes.
+but in the literature ~\cite{fmd91}[3-116] is is described as a simple component with a set of failure modes.
 
 % Idea stage on this section, integrated circuits and some compond parts (like digital resistors)
 % are treated like base components. i.e. this sets a precedent for {\dcs}.
@@ -1408,10 +1778,166 @@ failure modes combinations have been analysed as failure scenarios.
 %This AUTOMATIC check can reveal WHEN double checking no longer necessary 
 %in the hierarchy to cover dub sum !!!!! YESSSS
 
+\section{Conclusion}
+%\subsection{Evaluation of FMMD}
+
+%By applying the methodology in section \ref{fmmdproc}, the wishlist can
+%now be evaluated for the proposed FMMD methodology.
+
+We evaluate the FMMD method using the criteria in section \ref{fmmdreq}.
+Table \ref{tbl:comparison} compares the current methodologies and FMMD using these criteria.
+{ %\small
+\begin{itemize}
+\item{State explosion is reduced,}
+%State Explosion is reduced,
+because small collections of components are dealt within functional groups
+which are used to create derived components which are then used in an hierarchical manner.
+
+\item{All component failure modes must be considered in the model.}
+%All component failure modes must be considered in the model.
+Since the proposed methodology is bottom-up,
+this means that we can ensure/check that all component failure modes are handled.
 
 
+\item{ It should be straightforward to integrate mechanical, electronic and software models,}
+%It should be straight forward to integrate mechanical, electronic and software models,
+because FMMD models in terms of  failure modes only. % we have a generic failure mode entities to model.
+%We can describe a mechanical, electrical or software component in terms of its failure modes. 
+%
+Because of this 
+we can model and analyse integrated electromechanical systems, controlled by computers,
+using a common notation. An electronic/software FMMD example is given in~\ref{sec:elecsw}.
+
+\item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
+%It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
+The hierarchical nature, taking {\fg}s and deriving components from them, means that 
+commonly used {\dcs} can be re-used in a design % (for instance self checking digital inputs)
+or even in other projects where the same {\dc} is used. Several examples of re-used {\dcs}
+may be found in chapter~\ref{sec:chap5}.
 
 
+\item{ Formal basis: data should be available to produce mathematical proofs and traceability.}
+%It should have a formal basis, data should be available to produce mathematical proofs
+%for its results
+Because the failure mode model of a system is a hierarchy of {\fg}s and {\dcs},
+system level failure modes are traceable back down the fault tree to
+component level failure modes. 
+%
+This allows cut sets~\cite{nasafta}[Ch.1p3]
+to be determined by traversing the DAG from top level events down to their causes.
+
+
+% \item{ It should be capable of producing reliability and danger evaluation statistics.}
+% The minimal cuts sets for the system level failures can have computed MTTF
+% and danger evaluation statistics sourced from the component failure mode statistics~\cite{fmd91,mil1991}.
+
+% \item{ It should be easy to use, ideally 
+% using a graphical syntax (as opposed to a formal mathematical one).}
+% A modified form of constraint diagram (an extension of Euler diagrams) has
+% been developed to support the FMMD methodology.
+% This uses Euler circles to represent failure modes, and spiders to collect symptoms, to
+% advance a {\fg} to a {\dc}.
+
+
+% \item{ From the top down the failure mode model should follow a logical de-composition of the functionality
+% to smaller and smaller functional modules \cite{maikowski}.}
+% The bottom-up approach fulfils the  logical de-composition requirement, because the {\fg}s
+% are built from components performing a given task. 
+% 
+
+\item{ Multiple failure modes (conjunction - where more that one failure mode is active) 
+may be modelled from the base component level up.}
+%Multiple failure modes (conjunction) may be modelled from the base component level up.
+By breaking the problem of failure mode analysis into small stages
+and building a hierarchy, the problems associated with needing to 
+analyse all possible combinations of base level components
+within a system are reduced.
+
+% by an exponential order.
+This is because the multiple failure modes considered
+within {\fgs} have fewer failure modes to consider 
+at each FMMD stage.
+Where appropriate, multiple simultaneous failures can be modelled by
+introducing {\fcs} %test~cases 
+where the conjunction of failure modes is considered.
+An example demonstrating multiple failure mode analysis may be found in section~\ref{sec:Pt100}.
+\end{itemize}
+}
+
+{ %\tiny
+\begin{table}[ht]
+\caption{Features of static Failure Mode analysis methodologies} % title of Table
+%\centering % used for centering table
+\begin{tabular}{||l|c|c|c|c|c||}
+\hline \hline
+% \textbf{Des.} & \textbf{FTA}  & \textbf{FMEA} &   \textbf{FMECA} & \textbf{FDEMA} &   \textbf{FMMD}   \\
+\textbf{\tiny Des.} & \textbf{\tiny FTA}  & \textbf{\tiny FMEA} &   \textbf{\tiny FMECA} & \textbf{\tiny FDEMA} &   \textbf{\tiny FMMD}   \\
+ \textbf{\tiny Crit.}  &   \textbf{}   & \textbf{}     &   \textbf{}      & \textbf{}      &   \textbf{}   \\
+%   R         &    wire        & res +         & res -    & description
+\hline
+\hline
+ C1: % state exp    
+                &  partial      &               &                 &               &   $\tickYES$  \\ \hline
+ C2: % $\forall$ failures 
+                &               &$\tickYES$  &    $\tickYES$   &    $\tickYES$ &  $\tickYES$  \\  \hline
+ C3: %mech,elec,s/w & $\tickYES$    
+                &               &                 &               &             & $\tickYES$ \\  \hline
+ C4: %modular        
+                &               &               &                 &  partial      &  $\tickYES$   \\ \hline
+ C5: %formal         
+                &  partial     &  partial       &  partial       &  partial    &  $\tickYES$   \\ \hline
+ C6: %multiple fm    
+                &   $\tickYES$  &               &                 &  partial    &  $\tickYES$    \\ \hline
+\hline
+\hline
+\end{tabular} 
+\label{tbl:comparison}
+\end{table}
+}
+%\clearpage
+
+
+%\subsection{}
+
+
+%This new approach is called 
+Failure Mode Modular De-Composition (FMMD) is designed 
+to be a more rigorous  and `data~complete' model than
+the current four approaches.
+%
+That is, 
+from an FMMD model, we should be able to 
+derive outline models that the other four methodologies would have been 
+able to create. As this approach is modular, many of the results of 
+analysed components may be re-used in other projects, so 
+test efficiency is improved.
+%Clearly the more complex the original system is the more benefit,
+%i.e. less components and derived components, will be produced from decomposing the 
+%system into functional groups.
+
+FMMD is based on generic failure modes, so it is not constrained to a 
+particular field. It can be applied to mechanical, electrical or software domains. 
+It can therefore be used to analyse systems comprised of electrical,
+mechanical and software elements in one integrated model.
+Furthermore the reasoning path is traceable. By being able to trace a 
+top level event down through derived components, to base component
+failure modes, with each step annotated as {\fcs}, the model is easier to maintain.
+
+The example used here is deliberately small for the purpose
+of being presenting the methodology showing  more than only one stage of hierarchy,
+worked examples for common electronic circuits, digital analogue hybrids and software electronic
+hybrid systems are given in chapter~\ref{sec:chap5}.
+%FMMD has been applied
+%to larger systems encompassing mechanical, electrical and software
+%elements. 
+FMMD represents a new technique in that it
+can address all the criteria in table 3, whereas the other methodologies
+can only cover some.
+
+
+FMMD not only has advantages of efficiency (reduction of state explosion), it also
+provides the capability to model entire electro-mechanical-software systems using a common notation
+and process.
 %\ifthenelse {\boolean{paper}}
 %{
 %\input{abstract}

submission_thesis/CH5_Examples/copy.tex

@@ -1,5 +1,5 @@
 %\clearpage %\pagenumbering{arabic}
-
+\label{sec:chap5}
 
 This chapter demonstrates FMMD applied to 
 a variety of common electronic circuits.
@@ -3024,7 +3024,7 @@ condition in higher levels of the system.
 
 
 \section{Applying FMMD to Software}
-
+\label{sec:elecsw}
 FMMD  can be applied to software, and thus we can build complete failure models
 of typical modern safety critical systems.
 With modular FMEA i.e. FMMD %(FMMD) 

submission_thesis/thesis.tex

@@ -63,7 +63,7 @@
                                               % numbers at outer edges
 \pagenumbering{arabic}                        % Arabic page numbers hereafter
 \cfoot{Page \thepage\ of \pageref{LastPage}}
-\lfoot{Brighton University 2011}
+\lfoot{Brighton University 2012}  %% Year keeps fucking incrementing
 \rfoot{R.P.Clark \today}
 \lhead{Failure Mode Modular De-Composition}
 \rhead{PhD Thesis}
@@ -128,6 +128,6 @@
 \addcontentsline{toc}{chapter}{Glossary}
 
 \bibliographystyle{plain}
-\bibliography{vmgbibliography,mybib}
+\bibliography{../vmgbibliography,../mybib}
 
 \end{document}

vmgbibliography.bib

@@ -11,6 +11,12 @@
   year =         {2007}
 }
 
+@MISC{Clark_fastzone,
+	    author = {Robin Clark},
+	        title = {Fast Zone Discrimination},
+		    year = {2007},
+  booktitle =    {Submitted to Visual Languages and Computing 2007},
+}
 
 
 @ARTICLE{stapleton:atpieds,