CH4 AF inspired edit but went on various tangents.

PLT for STATEEX definition!

mybib.bib

@@ -998,6 +998,12 @@ ISSN={1530-2059},}
   YEAR =         "2002"
 }
 
+@BOOK{probstatcrash,
+  AUTHOR =       " M~R~Spiegel, J~Schiller, A~Srinivasan",
+  TITLE =        "Probability and Statistics Crash Course : SHCAUM'S :  ISBN 0-07-138341-7",
+  PUBLISHER =    "McGraw Hill",
+  YEAR =         "2001"
+}
 
 @BOOK{probstat,
   AUTHOR =       " M~R~Spiegel",

submission_thesis/CH1_introduction/copy.tex

@@ -89,12 +89,14 @@ use.
 It then reveals common flaws 
 which make them unsuitable for the higher safety requirements of the 21st century.
 %
+\fmmdglossSTATEEX
 Problems with state explosion in failure mode reasoning and the current difficulties %impossibility
 of integrating software and hardware failure mode models~\cite{1372150} are the most obvious of these. %flaws.
 %
 These four current methodologies are described in chapter~\ref{sec:chap2} and %the advantages and drawbacks
 %of each FMEA variant are examined 
 critically assessed in chapter~\ref{sec:chap3}.
+\fmmdglossSTATEEX
 In chapter~\ref{sec:chap4}, a new methodology is proposed which addresses the state explosion problem
 and using contract programmed software, allows the modelling of integrated
 software/electrical systems.
@@ -152,6 +154,7 @@ now required to be analysed~\cite{en298}[9.1.5].
 %
 This, from a state explosion problem alone,
 meant that it was going to be virtually impossible to perform.
+\fmmdglossSTATEEX
 %
 To compound the problem, %state explosion problem
 FMEA has a deficiency of repeated work, as each component failure is typically represented
@@ -174,6 +177,7 @@ to logarithmic order~\cite{ctw}[pp.401-3].
 %
 The author wondered if this thinking could be applied to the state explosion problems encountered in FMEA.
 %
+\fmmdglossSTATEEX
 %Following the concept of de-composing a problem, and thus simplifying the state explosion---using the thinking behind
 %the fast Fourier transform (FFT)~\cite{fpodsadsp}[Ch.8], which takes a complex intermeshed series of real and imaginary  number calculations
 %and by de-composing them, simplifies the problem.
@@ -201,6 +205,7 @@ representing a failure mode model for the complete system had been created.
 Double simultaneous failure mode checking can be applied as
 the number of components
 in each {\fg} is typically small; state explosion problems are thus avoided. % for the general case. % AF says `in the general case' here 12JAN2013
+\fmmdglossSTATEEX
 %
 %
 % If we apply

submission_thesis/CH2_FMEA/copy.tex

@@ -991,7 +991,7 @@ would give an exhaustive reasoning distance---for single failure analysis---of 3
 The discussion on reasoning distance leads provides us with a metric to examine
 the state explosion problems associated with forward search failure investigation
 methodologies.
-
+\fmmdglossSTATEEX
 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.
@@ -1003,7 +1003,7 @@ of failure effects, than for a very large system where there are more variables
 \subsection{FMEA and the  State Explosion Problem}
 \label{sec:xfmea}
 \paragraph{Problem of which components to check for a given {\bc} {\fm}.}
-
+\fmmdglossSTATEEX
 FMEA for a safety critical certification~\cite{en298,en61508} will have to be applied
 to all known failure modes of all components within a system.
 %
@@ -1035,7 +1035,7 @@ This would mean an order of $O(N^2)$ number of checks to perform
 to undertake an `exhaustive~FMEA'. Even small systems have typically
 100 components, and they typically have 3 or more failure modes each, which would give
 $100*99*3=29,700$ as a reasoning distance.
-
+\fmmdglossSTATEEX
 \paragraph{Exhaustive FMEA and double failure scenarios.}
 %
 %\paragraph{Exhaustive Double Failure FMEA}
@@ -1061,6 +1061,7 @@ Current FMEA methodologies cannot consider---for the reason of state explosion--
 We define exhaustive FMEA ({\XFMEA}) as examining the effect of every component failure mode
 against the remaining components in the system under investigation.
 %
+\fmmdglossSTATEEX
 Because we cannot, for practical reasons, perform XFMEA, 
 we rely on  experts in the system under investigation
 to perform a meaningful FMEA analysis.
@@ -1144,24 +1145,39 @@ An example PFMEA report is presented in table~\ref{tbl:pfmeareport}.
 % \end{figure}
 FMECA places emphasis on determining criticality rather than the cost of system failures.
 %
-It applies Bayesian statistics (probabilities of component failures
+%
+It applies Bayesian statistics within the FMEA process (i.e. using probabilities of component failures
 and the probability of those failures causing given system level failures)
 to determine the risk of system level events/symptoms.
-The results of the probabilities for the system level failures
+%
-are multiplied by the operational time of the system.
+%
+The results of these risk probabilities, i.e. for system level failures,
+are then multiplied by the estimated operational time of the system.
+%
 For instance a military or emergency  system may be typically operational for
-a given number of hours. This in conjunction with the severity
+a given number of hours. The risk against time value, in conjunction with the severity
-of the system level event gives us a level of criticality.
+of the system level event gives a `criticality~level'.
 %
 %Also the probability of the system failure causing a critical event.
 %
+Bayes' theorem can be seen as a theory on the `probability~of~causes'~\cite{probstatcrash}[p.9].
+%
+A given component failure may for instance, be associated with
+a particular system failure to a calculated, or measured from field~data, statistical probability.
+%
 Applying Bayesian statistics to failure analysis, suffers the 
 problem that correlation does not imply causation~\cite{bayesfrequentist}.
 %
 However, correlation is evidence for causation, and maybe the only evidence to hand
 and this is the justification behind its use.
+%
+This implies a weakness in the FMECA philosophy. It means that
+failure causes can be inferred, rather than analytically
+determined, to become part of the failure mode model.
+%
 A history of the usage and development of FMECA may be found in~\cite{FMECAresearch}.
-
+ \fmmdglossFMECA
+ 
 \paragraph{ FMECA - Failure Modes Effects and Criticality Analysis.}
 Very similar to PFMEA, but instead of cost, a criticality or
 seriousness factor is ascribed to putative top level incidents.
@@ -1179,9 +1195,9 @@ a particular failure~mode occurring within a component~\cite{fmd91}.
 %A component with N failure modes will thus have
 %have an $\alpha$ value associated with each of those modes.
 %As the $\alpha$ modes are probabilities, the sum of all $\alpha$ modes for a component must equal one.
-
+%
-
+\fmmdglossFMECA
-
+%
 \paragraph{ FMECA - Failure Modes Effects and Criticality Analysis.}
 \textbf{FMECA $\beta$ value.}
 The second probability factor $\beta$, is the probability that the failure mode
@@ -1203,13 +1219,13 @@ A weighting factor to indicate the seriousness of the putative system level erro
 \begin{equation}
  C_m  =  {\beta} .  {\alpha} . {{\lambda}_p} . {t} . {s}
 \end{equation}
-
+\fmmdglossFMECA
 The highest $C_m$ values would represent the most dangerous or serious
 system level failures.
 The highest $C_m$ values would be at the top of a `to~fix' list
 for a project manager, and some levels of risk may be considered unacceptable
 and require re-design of some systems.
-
+\fmmdglossFMECA
 
 \section{FMEDA - Failure Modes Effects and Diagnostic Analysis}
 %

submission_thesis/CH3_FMEA_criticism/copy.tex

@@ -24,6 +24,7 @@ A major problem is with the scope of
 examination---i.e. which/how~many components should be checked against a particular failure mode---to
 apply for FMEA analysis.
 %
+\fmmdglossSTATEEX
 Checking all possible combinations of {\fms} against all components quickly leads to a state explosion problem. %:
 %defining limits for the number of components to check for against given {\bc}
 %{\fms} could address this.
@@ -48,6 +49,7 @@ multiple failure analysis~\cite{FMEAmultiple653556,maikowski}.
 The main reasons for this are that in electronics, each failure
 can introduce a circuit topology change and state explosion
 means there can be  extremely large numbers of double failures to check. 
+\fmmdglossSTATEEX
 %
 In software, in a similar vein,
 one failure can influence the programmatic behaviour and decisions made, 
@@ -158,6 +160,7 @@ FMEA results.
 Traditional FMEA cannot ensure that each failure mode of all its
 components are checked against any other components in the system which
 it may affect, due to state explosion.
+\fmmdglossSTATEEX
 %
 FMEA is therefore performed using heuristics % at best
 to decide on
@@ -183,7 +186,7 @@ as defined in equation~\ref{eqn:fmea_single},
 %
 % This figure would mean we could compare the maximum number of checks (i.e. exhaustive %rigorous 
 % analysis) with the number actually performed.
-Comlexity comparision means this maximum number of checks (i.e. exhaustive %rigorous 
+Comlexity comparision here, means the maximum number of checks (i.e. exhaustive %rigorous 
 analysis) could be compared to the number actually performed.
 %
 In effect a yard~stick for the amount of work performed
@@ -203,6 +206,7 @@ is termed a `{\fg}'.
 Potentially, using {\fgs}, is a way of de-composing
 the problem and reducing the $O(N^2)$ state explosion effect
 associated with XFMEA. 
+\fmmdglossSTATEEX
 %
 That is if the analysis problem can be broken into smaller steps, involving
 small groups of components, XFMEA could be applied within those, without
@@ -535,6 +539,7 @@ in an improved FMEA methodology,
     \item modular --- i.e. usable in a distributed system.
   % \item  
 \end{itemize}
+\fmmdglossSTATEEX
 %
 %FMEDA is a modern extension of FMEA, in that it will allow for 
 %self checking features, and provides detailed recommendations for computer/software architecture,

submission_thesis/CH4_FMMD/copy.tex

@@ -104,13 +104,12 @@ All the failure modes of all the components within a {\fg} are collected.
 %
 %A flat set is a set containing just the failure modes and not sets of failure modes~\cite{joyofsets}[p.8].
 %
-%In practical term each component failure mode is considered as a `failure~scenario' or 'test~case'
+Each component failure mode can considered as a `failure~scenario' or 'test~case'
-%for the {\fg}.
+applied to a {\fg}.
 %
-Each of these failure modes %, and optionally combinations of them, are
+Each of these failure modes, and optionally combinations of them, are
-%formed into failure~scenarios which
+formed into test~cases which
-are
+are analysed for their effect on the failure mode behaviour of the `{\fg}'.
-analysed for their effect on the failure mode behaviour of the `{\fg}'.
 %
 Once we have the failure mode behaviour of the {\fg}, we can determine its symptoms of failure.
 %,
@@ -170,329 +169,10 @@ In this way we can incrementally apply FMEA to an entire system. %, with documen
 This has advantages of concentrating
 effort in where modules interact (interfaces), of
 being able to re-use work and savings in the complexity of performing
-FMEA (because the analysis is typically performed in several small stages).
+FMEA (because the analysis is typically performed in several small stages
+thus avoiding state explosion).
 %A  notation is then described to index and classify objects created in FMMD hierarchical models.
-
+\fmmdglossSTATEEX
-
-
-% \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 reachability.}
-% \label{sec:rd}
-% 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.
-% %In electronics terms, all components on the signal path from the component that failed.
-% The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all the components
-% that must interact along the signal path 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.
-% 
-% Reasoning distances will be large for complicated systems, and this is therefore a weakness in both
-% FMEA and FTA type analyses. This concept is developed further to create a metric for comparing 
-% complexities from FMEA and FMMD analysis in section~\ref{sec:cc}.
-% 
-% % 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 (which is yet to be widely employed in international standards) 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 separately 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} from which 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 
-% %described in this chapter.
-% %When building a system from components, 
-% %we should be able to find all known failure modes for each component.
-% %For most common electrical and mechanical components, the failure modes
-% %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$.
-% 
-% \label{defs}
-% %%
-% %% Paragraph component and its relationship to its failure modes
-% %%
 
 
 \section{Worked Example: Non-Inverting Amplifier}
@@ -525,7 +205,7 @@ defined by $ G_v = 1 + \frac{R2}{R1} $ at the output.
 \paragraph{Analysing the failure modes of the Potential Divider.}
 \label{subsec:potdiv}
 Since the resistors work to provide a clearly defined function, that of a potential divider,
-we can treat them as a collection of components with a specific functionality---which can be termed a `{\fg}'. 
+we can treat them as a collection of components with a specific functionality---i.e. a `{\fg}'. 
 This {\fg} has two members, $R1$ and $R2$.
 %
 The potential divider circuit can be considered as a component
@@ -590,7 +270,7 @@ for it outputting a low voltage `LowPD'. % Andrew asked for this to be defined b
 %
 { \small
 \begin{table}[ht]
-\caption{Potential Divider: Failure Mode Effects Analysis: Single Failures} % title of Table
+\caption{Potential Divider: FMEA for single failures} % title of Table
 \centering % used for centering table
 \begin{tabular}{||l|c|c|l||}
 \hline \hline
@@ -995,7 +675,7 @@ showing the choice of de-composition of the system into {\fgs} (see figure~\ref{
 %where the curves
 %define the components and {\dcs} used to form the INVAMP model, see figure~\ref{fig:eulerfmmd}.
 %
-\begin{figure}[h]
+\begin{figure}[h]+
  \centering
  \includegraphics[width=300pt]{./CH4_FMMD/eulerfmmd.png}
  % eulerfmmd.png: 413x207 pixel, 72dpi, 14.57x7.30 cm, bb=0 0 413 207
@@ -1004,6 +684,8 @@ the components have been grouped into {\fgs} and then used as {\dcs} to build th
  \label{fig:eulerfmmd}
 \end{figure}
 %
+%\clearpage %%% This figure seems to escape furher down the chapter
+%
 We can now examine the failure mode relationships in the {\dc} {\em INVAMP} by drawing it as a DAG.
 %expand the {\em PD} {\dc} and  have a full FMMD failure %mode 
 %model
@@ -1025,108 +707,14 @@ that can cause them.
 That is, we can trace failure mode effects 
 from base component level to the top and vice versa.
 
-
 \fmodegloss
 \fmmdgloss
 \fmmdglossFG
 \fmmdglossDC
 \fmmdglossSYMPTOM
 
-
-% \paragraph{Worked example. Effect on State explosion.}
-% The potential divider {\dc} reduced the number of failures to consider from four to two.
-% The op-amp and potential divider modelled together, reduced the number of 
-% base component failures from eight to three failure symptoms. 
-% %
-% In general,
-% because symptoms are collected, we can state
-% the number of failure symptoms for a {\fg} will be less than or equal to the number
-% of component failures.
-% % In practise the number of symptoms is usually around half the 
-%number of component failure modes, for each stage of FMMD analysis.
-%This methodology has also been applied elsewhere to the inverting amplifier configuration.
-%One can then use use {\dcs} in more complex circuits where the advantages of FMMD become more obvious,
-%(such as $8^{th}$ order filters using four bi-quad op-amp stages).
-
-
-
-%% GARK END
-
-
-
-%\clearpage
-
-% When analysing a safety critical system using 
-% any form of Failure Mode Effects Analysis (FMEA), we need clearly defined failure modes for
-% all the components that are used in a given system.
-% %
-% We introduce a constraint  that
-% component failure modes must be mutually exclusive within individual components.
-% This concept is later developed as the condition of `unitary state' fault modes (see section~\ref{sec:unitarystate}). 
-
 \section{Defining terms}
 
-% Here we define the terms as used in the worked example.
-% 
-% \begin{table}[h]
-% \center
-% \begin{tabular}{||p{3cm}|p{10cm}||} 
-% 
-% \hline \hline
-%   {\em Definition } & {\em Description}    \\ \hline
-% 
-% System & A product designed to  
-%         work as a coherent entity  \\  \hline  
-% 
-%  
-% 
-% Base Component & An atomic building block used at the lowest level of an FMMD model.
-%                 % \footnote{In the case of combinatorial packaged parts (such as a chip containing
-%                %  four op-amps, each op-amp on the chip is considered as one atomic, or {\em{\bc}}).}. %% where did this footnote GO????
-%                % seems like its a bug in TeX 04JUN2012
-%        \\
-% {\em Constraint} & This object must have a defined set of failure~modes. \\    \hline 
-% 
-% 
-% Component  & A building block, this may be a {\bc} or a {\dc}. \\%or manufacturers part. \\  
-% {\em Constraint} & This object must have a defined set of failure~modes. \\    \hline 
-% 
-% 
-% 
-% %Sub-system & A part of a system, sub-systems may contain sub-systems etc. \\ \hline % in FMMD terminology
-%              %this would be both a {\em{\dc}} and a {\fg}. \\
-% %{\em Constraint} & This object must have a defined set of failure~modes. \\    \hline 
-% 
-% %%A part failure mode is the way in which a component fails "functionally" on component level. Often a part has only a few failure modes. 
-% Failure mode & A failure mode~\cite{sccs}[p.8] is the way in which a component may fail functionally (i.e. the way in which it can fail to perform 
-% its intended function). A component will typically have few failure modes. \\     \hline 
-% 
-% Functional Grouping & A collection of 
-%                   components with a functional purpose.
-%                   \\    \hline  
-% 
-% % Symptom      & A failure symptom of a {\fg}, caused by % WHICH MUST BE UNIQUE AND SEPARATE WITHIN THE \fg
-% %                a combination of its component failure modes. \\ \hline
-% 
-% 
-% Derived Component & A theoretical component, created to represent the failure
-%                     mode behaviour of a {\fg}. \\  
-%                     
-% {\em Constraint} & This object must have a defined set of failure~modes. \\    \hline 
-% UNITARY STATE NOT DISCUSSED HERE NOW......
-% Unitary State & A component with `unitary~state' failure modes, means that it cannot fail
-% with more than one of its failure modes at a time.\\    \hline 
-%%%% TOLD TO REMOVE THIS BUT FIDDLINGING HATAR TO HAVE TO DO IT
-% Failure Scenario & A single failure mode (or a combination), used to
-%                    determine failure mode effects on a {\fg}.
-%\\
-%  \hline
-% \end{tabular}
-% \caption{Failure Mode Modular De-composition: definitions and terms}
-% \label{tbl:fmmd_defs}
-% \end{table}
-
-
 \paragraph{A discussion on the terms Parts, Components and Base Components.}
 A component is anything we use to build a %a product or 
 system. 
@@ -1238,8 +826,9 @@ it performs a well defined function and it could be considered a design module.
 \paragraph{Functional grouping to {\dc} process outline.}
 %In choosing the lowest level (base component) sub-systems we would look 
 %for the smallest `functional~groups' of components within a system. 
-We %can 
+%We %can 
-define a {\fg} as a set of components that interact
+%define a 
+{\Fgs} have been defined as a set of components that interact
 to perform a specific function.
 %
 When we have analysed the fault behaviour of a {\fg}, we can treat it as a `black~box'.
@@ -1252,8 +841,7 @@ The {\fgs} fault behaviour will consist of a set of %
 failure modes caused by combinations
 of its component's failure modes.
 %
-We can thus create a new component derived from analysing the {\fg} where
+A new component can be derived from analysing the {\fg} where
-%
 the symptoms of failure of the {\fg} are the failure modes of this new `{\dc}'.
 %
 An outline of the FMMD process is itemised below:
@@ -1420,9 +1008,16 @@ it is common to term the modules identified as sub-systems.
 %
 \fmmdglossFTA
 \fmmdglossSS
+\fmmdglossFG
 %
-When modularising failure mode behaviour from the bottom up, it is more meaningful to call them `derived~components'.
+When modularising failure mode behaviour from the bottom up, 
+it is more meaningful to call them `{\dcs}'.
 %
+This is because they have been derived from the bottom-up according to functional 
+criteria, rather than with the top down approach, de-composed from 
+a system into 'sub-systems'.
+%
+\fmodegloss
 \fmmdglossDC
 %
 
@@ -1504,6 +1099,7 @@ especially where there are non-obvious top-level faults.
 The process for taking a {\fg}, analysing its failure mode behaviour, considering
 all the failure modes of all the components in the group
 and collecting symptoms of failure,  is termed `symptom abstraction'.
+\fmmdglossSA
 %
 This is dealt with in detail using an algorithmic description, in appendix \ref{sec:algorithmfmmd}.
 \fmmdglossFG
@@ -1526,7 +1122,7 @@ and creates a new {\dc} from it.
 %must consider all the failure modes of the components in the functional
 %group.
 The newly created {\dc} requires a set of failure modes of its own.
-As a derived component inherits component, the UML model shows
+As a derived component inherits from component, the UML model shows
 that it inherits the property of a set of failure modes.
 %
 %These failure modes are the failure mode behaviour---or symptoms---of the {\fg} from which it was derived.
@@ -1575,11 +1171,13 @@ The UML representation  (in figure \ref{fig:cfg}) shows a `{\fg}' having a one t
 
 \subsection{How the UML Meta Model maps to an FMMD Hierarchy}
 \label{sec:fmmd_uml}
+%
 The UML meta model above (see figure~\ref{fig:cfg}) describes a hierarchical structure. %% Might be a UML pattern that is well known ..... 05MAY2012
 This is because, as {\dcs} inherit the properties of 
 components, {\dcs} may be used to form {\fgs}.
 %
 Consider the hierarchy from the example in figure~\ref{fig:eulerfmmd}. % ~\ref{fig:dc2}.
+%
 The lowest level in this hierarchy are the {\bcs}, the resistors and the op-amp.
 %
 The resistors are collected into a {\fg}, and the ${PD}$ derived component created from its analysis, is shown enclosing R1 and R2. % above the {\fg}.
@@ -1590,8 +1188,11 @@ it in a {\fg} higher in the hierarchy.
 The {\em PD} derived component is now placed into a {\fg}
 with the op-amp. 
 %
-This {\fg} is now analysed and a {\dc} created to 
+This {\fg} is now analysed and a {\dc} created to represent the failure mode behaviour 
-represent the failure mode behaviour of the {\em INVAMP}.
+of the {\em INVAMP}\footnote{The results of this analysis are placed into the analysis~report. This will contain 
+mapping relationships between the component {\fms} and the {\dc} {\fms} and ideally, descriptions that would
+aid auditors to understand the reasoning behind each analysis test~case.}.
+\fmmdglossSS
 %
 %
 We may now use the  {\em INVAMP} {\dc} in even higher level {\fgs}.
@@ -1681,8 +1282,10 @@ a level 2 {\dc} ($\abslev=2$).
 Because {\fgs} may include components at varying levels 
 of $\abslev$, having it quickly available as an attribute
 will be required in practical implementations
-to order the tree, and assist in preventing recursion in the hierarchy.
+to order the tree, and assist in preventing recursion in the hierarchy (i.e. where
-The abstraction level concept is formally defined in section~\ref{sec:abstractionlevel}.
+a {\fg} could erroneously include a component above its-self in the hierarchy).
+%
+The abstraction level concept is formally defined in appendix~\ref{sec:abstractionlevel}.
 
 % \section{Set Theory Description}
 % 
@@ -1807,7 +1410,7 @@ 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}
+create failure modes models that have a many to one mapping from {\bc} {\fm}
 to system level failure, or symptom (see section~\ref{sec:onetoone}).
 %
 \fmmdglossMUTEX
@@ -1821,6 +1424,10 @@ we can have a final stage where we consider the subjective or contextual effects
 With traditional FMEA methodologies we 
 have to make this decision (the contextual effects) for each component {\fm} in the system.
 
+
+
+
+
 \paragraph{State explosion problem of FMEA solved by FMMD.}
 %
 Because FMMD considers failure modes within functional groups;
@@ -1829,8 +1436,16 @@ mode could be considered in the context of all other components in the system---
 %
 With FMMD, because the {\fgs} have small numbers of components in them, we can easily  apply XFMEA within the {\fgs}.
 %
+In broad terms, FMMD mitigates state explosion by reducing the number of checks---{\fms} against components)---to perform.
+%
 This issue addressed formally in section~\ref{sec:cc}.
 \fmmdgloss 
+\fmmdglossSTATEEX
+
+
+
+
+
 
 \paragraph{Uses of the FMMD failure mode model.}
 %
@@ -1842,7 +1457,7 @@ provides  a forward search derived failure mode model.
 %
 This means that for every system level failure we can traverse back to possible failure causes
 in the base components. Coupled with MTTF statistics for the base components
-this allows use to predict statistical failure rates for system level failures (this is 
+this allows prediction of statistical failure rates for system level failures (this is 
 described in greater detail in section~\ref{sec:determine_fms}).
 %
 We can also use the FMMD model to derive information

submission_thesis/CH7_Evaluation/copy.tex

@@ -871,6 +871,7 @@ each component would not contribute $N$ failure modes, % to consider
 but potentially
 $2^N$. 
 %
+\fmmdglossSTATEEX
 This would make the job of analysing the failure modes
 in a {\fg} impractical due to state explosion. %the sheer size of the task.
 %Note that the `unitary state' conditions apply to failure modes within a component.

submission_thesis/CH8_Conclusion/copy.tex

@@ -2,6 +2,7 @@
 \fmeagloss
 This study has examined the processes and state of the art of the four main FMEA variants.
 %
+\fmmdglossSTATEEX
 It has exposed shortcomings in these methodologies, which can be summed up as an inability to 
 model hybrid software and hardware systems in a satisfactory manner, a problem with state explosion
 and difficulty of re-use of analysis because there is no support for modularity.
@@ -18,6 +19,7 @@ which deliberately introduced varying circuit
 topologies with conventional and circular signal paths
 and mixed digital and analogue designs.
 %
+\fmmdglossSTATEEX
 For all these examples, the state explosion related performance was compared with that of
 traditional FMEA. 
 %
@@ -64,7 +66,7 @@ In conclusion then, a new method of failure analysis has been devised  which imp
 %     \item modular --- i.e. usable in a distributed system.
 %   % \item  
 % \end{itemize}
-
+\fmmdglossSTATEEX
 \begin{itemize}
  \item FMMD provides the means to create failure models that integrate software and hardware,
  \item the state explosion related to exhaustive FMEA solved,

submission_thesis/appendixes/algorithmic.tex

@@ -173,7 +173,7 @@ for each test case.
 
 
 \subsection{Single stage of FMMD described as a `symptom~abstraction~process'}
-
+\fmmdglossSA
 
 A single  stage of FMMD analysis can be described as symptom abstraction.
 %
@@ -216,7 +216,7 @@ $$
 %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent 
 \derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
 $$
-
+\fmmdglossSA
 %The next section describes the details of the symptom abstraction process.
 
 }
@@ -263,7 +263,7 @@ The algorithm, represented by the symbol `$\derivec$', is described using five a
 % 
 % %\clearpage
 % $$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} .$$
-
+\fmmdglossSA
 \begin{algorithm}
 \caption{Derive new `Component' $DC$ from a given {\fg} $FG$: $\derivec(FG)$} 
 \begin{algorithmic}[1]
@@ -279,7 +279,7 @@ The algorithm, represented by the symbol `$\derivec$', is described using five a
 \end{algorithmic}
 \label{alg66}
 \end{algorithm}
-
+\fmmdglossSA
 The symptom abstraction process allows us to take a {\fg} of components,
 analyse the failure
 mode behaviour and create a new entity, a {\dc} that has its own set of failure modes.
@@ -294,7 +294,7 @@ from the bottom-up.
 
 %\clearpage
 \subsection{Determine Failure Modes to Examine}
-
+\fmodegloss
 The first stage is to find the failure modes to consider for
 analysis,
 using the earlier definition of the function $fm$ applied to
@@ -346,6 +346,8 @@ the failure modes for a particular test case have been chosen by
 a human operator and are additional to those chosen by the automated process (i.e they are 
 special test~cases involving multiple failure modes).
 %
+\fmmdglossMUTEX
+%
 The function \textbf{isunitarystate} 
 takes as its argument a test~case
 and returns true if no pairs of that test~case's
@@ -605,6 +607,7 @@ We now have a set $SP$ of the symptoms of failure.
 \ifthenelse {\boolean{paper}}
 {
 Component failure modes must be mutually exclusive.
+\fmmdglossMUTEX
 That is to say only one specific failure mode may be active at any time.
 This condition/property has been termed unitary state failure mode.
 Ensuring that no result belongs to more than

submission_thesis/style.tex

@@ -50,6 +50,7 @@
 \newcommand{\DC}{\ensuremath{{DC}}}
 \newcommand{\fg}{\emp functional~grouping}
 \newcommand{\fgs}{\emp functional~groupings}
+\newcommand{\Fgs}{\emp Functional~groupings}
 \newcommand{\dc}{\emp derived~component}
 \newcommand{\dcs}{\emp derived~components}
 \newcommand{\bc}{\emp base~component}
@@ -125,12 +126,20 @@ FMEA applied for cost benefit analysis typically used in mass production}}}
 Software Fault Tree Analysis (SFTA): 
 top down failure investigation applied to software}}}
 
+\newcommand{\fmmdglossSA}{\glossary{name={Symptom Abstraction},description={
+By applying failure mode analysis to a module, the symptoms of failure for the it are determined
+given the failure modes of its components, its topology and expected behaviour.}}}
 
 \newcommand{\fmmdglossMUTEX}{\glossary{name={mutually~exclusive},description={
 Mutual exclusivity applied to component failure modes
 means that for each component it is ensured that
 only one of its failure modes may be active at any given time}}}
 
+\newcommand{\fmmdglossSTATEEX}{\glossary{name={State~explosion},description={
+State Explosion is the effect where very large numbers of combinations of conditions, or combinations of
+conditions and entities have to be processed. The number to be processed can quickly become too large 
+for practical consideration, and when this happens `state~explosion' can be said to have occurred.
+}}}
 
 \newcommand{\fmmdglossFTA}{\glossary{name={FTA},description={
 Fault Tree Analysis (FTA).