Merge branch 'master' of dev:/home/robin/git/thesis

Conflicts:
	lifecycle_modelling/paper.tex

common_mode/Makefile

@@ -0,0 +1,20 @@
+
+#
+
+
+paper:	paper.tex common_mode_paper.tex
+	#latex paper.tex
+	#dvipdf paper     pdflatex cannot use eps ffs
+	pdflatex paper.tex
+	mv paper.pdf common_mode.pdf
+	okular common_mode.pdf
+
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+common_mode_paper.tex: common_mode.tex paper.tex
+	cat common_mode.tex | sed 's/common_mode\///' > common_mode_paper.tex
+
+bib:	
+	bibtex paper

common_mode/common_mode.tex

@@ -0,0 +1,98 @@
+
+
+
+
+\ifthenelse {\boolean{paper}}
+{
+\abstract{ 
+This paper describes how the Failure Mode Modular De-composition (FMMD) methodology 
+can be applied to the problems of common mode failure
+analysis.
+%
+Common mode failures are often difficult to
+determine in embedded real time systems.
+%
+Environmental effects can lead to component failure
+modes, that can occur in separate sub-systems
+in a system, but interact to create unexpected fault.
+% WHAT IS DID
+The FMMD methodology can model and warn for two types of common mode failures.
+Failures caused by separate sub-systems relying on 
+a common component, and environmental effects that can induce failure
+modes in components in separate sub-systems.
+% WHAT I FOUND
+From the FMMD data model it is possible to link the environmental effects
+and ensure determine the weak points in a design, where the failure modes may interact.
+For the component dependency case, the dependent component 
+can be automatically highlighted by traversing the data model.
+% WHY YOU WOULD WANT TO READ IT
+This feature of FMMD proides another tool in the safety engineers
+repotiore, one that can shake out difficult to find common mode failure
+effects. 
+}
+}
+{
+\paragraph{Chapter overview}
+This chapter describes how the % Failure Mode Modular De-composition (FMMD) 
+FMMD methodology 
+can be applied to the problems of common mode failure
+analysis.
+%
+Common mode failures are often difficult to
+determine in embedded real time systems.
+%
+Environmental effects can lead to component failure
+modes, that can occur in separate sub-systems
+in a system, but interact to create unexpected fault.
+% WHAT IS DID
+The FMMD methodology can model and warn for two types of common mode failures.
+Failures caused by separate sub-systems relying on 
+a common component, and environmental effects that can induce failure
+modes in components in separate sub-systems.
+% WHAT I FOUND
+From the FMMD data model it is possible to link the environmental effects
+and ensure determine the weak points in a design, where the failure modes may interact.
+For the component dependency case, the dependent component 
+can be automatically highlighted by traversing the data model.
+% WHY YOU WOULD WANT TO READ IT
+This feature of FMMD proides another tool in the safety engineers
+repotiore, one that can shake out difficult to find common mode failure
+effects. 
+
+}
+
+ 
+\section{Introduction}
+
+\ifthenelse {\boolean{paper}}
+{
+paper
+}
+{
+chapter
+}
+
+
+Outline the fmmd process.
+
+
+Show modules with common dependencies (like on a power supply, a powersupply could have a fault
+like nopisy output)
+
+
+Trace a theoretical example and show how FMMD detects this (common dependency - like two
+{\dc}s being depemdent on the same failure mode.
+
+
+Then show an environmental effect, such as temperature and how 
+it can induce faults in sepatate modulkes that
+would not be obviously related.
+
+Trace a theoretical example and show how FMMD detects this
+i.e. the environmental factor affecting both systems and causing a problem.
+
+
+what about the third way it can be affected.
+
+Like a chain of relays...... all could get welded .... think about that one.....
+

common_mode/paper.tex

@@ -0,0 +1,31 @@
+
+\documentclass[a4paper,10pt]{article}
+\usepackage{graphicx}
+\usepackage{fancyhdr}
+\usepackage{tikz}
+\usepackage{amsfonts,amsmath,amsthm}
+\input{../style}
+\usepackage{ifthen}
+\newboolean{paper}
+\setboolean{paper}{true} % boolvar=true or false
+
+
+%\newtheorem{definition}{Definition:}
+
+\begin{document}
+\pagestyle{fancy}
+
+%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}}         
+%\innerfoot{{\small\bf R.P. Clark } }   
+                                              % numbers at outer edges
+\pagenumbering{arabic}                        % Arabic page numbers hereafter
+\author{R.P.Clark}
+\title{Modelling and Uncovering Common Mode Failures using FMMD}
+\maketitle 
+\input{common_mode_paper}
+
+\bibliographystyle{plain}
+\bibliography{../vmgbibliography,../mybib}
+
+\today
+\end{document}

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -664,6 +664,12 @@ such as Bayes theorem \cite{probstat}.
 %%- the other parts were just fragments to illustrate points
 %%-
 %%-
+\section{Complete UML Diagram}
 
+\section{From UML Model to Data Model}
+\subsection{Directed Acyclic Graph}
+\subsection{Traversing the datamodel}
+\subsubsection{Common mode failure detection}
+\subsubsection{Common dependency detection}
 
 \vspace{40pt}

fmmd_concept/fmmd_concept.tex

@@ -14,7 +14,7 @@ incremental and rigorous approach.
 %% What I have done
 %%
 The Four main static failure mode analysis methodologies were examined and 
-in in the context of newer European safety standards assessed.
+in the context of newer European safety standards assessed.
 Some of the defeciencies in these methodologies lead to
 a wish list for a more ideal methodology.
 
@@ -27,7 +27,7 @@ methodology is developed. The has been named Failure Mode Modular De-Composition
 %% Sell it
 %%
 In addition to addressing the traditional weaknesses of
-Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Faliue Mode Effects Criticallity Analysis (FMECA)
+Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Failure Mode Effects Criticallity Analysis (FMECA)
 and Failure Mode Effects and Diagnostic Analysis (FMEDA), FMMD provides the means to model multiple failure mode scenarios 
 as specified in newer European Safety Standards \cite{en298}.
 The proposed methodology is bottom-up and 
@@ -145,14 +145,14 @@ are held in a computer program, we can determine if the model is complete
 
 \subsection{General Comments on bottom-up and top down approaches}
 
-\paragraph{A general Problem with top-down}
+\paragraph{A general defeciency in top-down systems analysis}
 With a top down approach the investigator has to determine
-a set of undesireable outcomes or accidents.
+a set of undesirable outcomes or accidents.
 As most accidents are unexpected and the causes unforseen \cite{safeware} 
 it is fair to say that a top down approach is not guaranteed to
 predict all possible undesirable outcomes.
 It also can miss known component failure modes, by
-simple not de-composing down to that level of detail.
+simply not de-composing down to that level of detail.
 
 \paragraph{A general problem with bottom-up}
 With the bottom up techniques we have all the known component failure modes
@@ -165,22 +165,22 @@ we cannot consider them all and human judgement is used to
 decide which interactions are important.
 
 Let N be the number of components in our system, and K be the average number of component failure modes
-(ways in which the component can fail). The total number of base component failure modes
+(ways in which the component can fail). The total number of base comp failure modes
-is $N \times K$. To even examine the affect that one failure mode has on all the other components
+is $N \times K$. To examine the affect that one failure mode has on all the other components
 will be $(N-1) \times N \times K$, in effect a set cross product.
 
 
 Complicate this further with applied states or environmental conditions
 and another order of cross product of complexity is added.
-We may have a peice of self checking circuity for instance that
+We may have a piece of self checking circuitry for instance that
 has two states, normal and testing mode commanded by a logic line.
 Or we may have a mechanical device that has a different 
-failure mode behaviour for say, differnet ambient pressures or temperatures.
+failure mode behaviour for say, different ambient pressures or temperatures.
 
 If $E$ is the number of applied states or environmental conditions to consider
 in a system, the job of the bottom-up analyst is complicated by a cross product factor again 
 $(N-1) \times N \times K \times E$.
-If we put some typical very small embedded system numbersi\footnote{these figures would
+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 sensor and heater circuit} into this, say $N=100$, $K=2.5$ and $E=10$
 we have $99 \times 100 \times 2.5 \times 10 = 247500 $.
 To look in detail at a quarter of a million test cases is obviously impractical.
@@ -188,7 +188,7 @@ To look in detail at a quarter of a million test cases is obviously impractical.
 If we were to consider multiple simultaneous failure modes
 we have yet another complication cross product.
 
-For instance for looking at double simultaneous failure modes 
+For instance for looking at double simultaneous failure modes, 
 the equation reads $(N-2) \times (N-1) \times N \times K \times E$.
 
 The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes and link them
@@ -198,8 +198,8 @@ component failure mode to the SYSTEM level.
 
 
 
-\paragraph{Ideal Static failure mode methodology}
+\paragraph{Ideal static failure mode methodology}
-An ideal Static failure mode methodology would build a failure mode model
+An ideal static failure mode methodology would build a failure mode model
 from which the traditional four models could be derived.
 It would address the short-comings in the other methodologies, and
 would have a user friendly interface, with a visual (rather than mathematical/formal) syntax with icons
@@ -217,7 +217,7 @@ of missing component failure modes \cite{faa}[Ch.9].
 %, or modelling at
 %a too high level of failure mode abstraction.
 FTA was invented for use on the minuteman nuclear defence missile
-systems in the early 1960's and was not designed as a rigorous
+systems in the early 1960s and was not designed as a rigorous
 fault/failure mode methodology. It is more like a structure to
 be applied when discussing the safety of a system, with a top down hierarchical
 notation, that guides the analysis. This methodology was designed for
@@ -244,7 +244,7 @@ The investigation will typically point to a particular failure
 of a component. 
 The methodology is now applied to find the significance of the failure.
 Its is based on a simple equation where $S$ ranks the severity (or cost \cite{fmea}) of the identified SYSTEM failure,
-$O$ its occurrance, and $D$ giving the failures detectability. Muliplying these
+$O$ its occurance, and $D$ giving the failures detectability. Muliplying these
 together, 
 gives a risk probability number (RPN), given by $RPN = S \times O \times D$.
 This gives in effect
@@ -286,7 +286,7 @@ The results, as with FMEA are an $RPN$ number determining the significance of th
 %%-WIKI- while various forms of FMEA predominate in other industries.
 
 
-\subsubsection{ FMEA weaknesses }
+\subsubsection{ FMECA weaknesses }
 \begin{itemize}
 \item Possibility to miss the effects of failure modes at SYSTEM level.
 \item Possibility to miss environmental affects.
@@ -314,7 +314,7 @@ The component may be mitigated by a vatriety of factors
 \item Coverage of self checking
 \end{itemize}
 
-Ultimately this tequnique calculates a risk factor for each component.
+Ultimately this technique calculates a risk factor for each component.
 The risk factors of all the components are summed and 
 give a value for the `safety level' for the equipment in a given environment.
 
@@ -327,32 +327,44 @@ give a value for the `safety level' for the equipment in a given environment.
 %%-• The design strength (de-rating, safety factors) and
 %%-• The operational profile (environmental stress factors).
 
-This uses MTFF and other statisical models to determine the probability of
+This uses MTFF and other statistical models to determine the probability of
-failures occurring. A component failure mode, given its MTTF
+failures occurring.
+%
+A component failure mode, given its MTTF
 the probability of detecting the fault and its safety relevant validation time $\tau$,
 contributes a simple risk factor that is summed
-in to give a final risk result. Thus a statistical
+in to give a final risk result. 
+%
+Thus a statistical
 model can be implemented on a spreadsheet, where each component
 has a calculated risk, a fault detection time (if any), an estimated risk importance
 and other factors such as de-rating and environmental stress.
 This can be calculated, with one component failure mode per row, on a spreadsheet
 and these are all summed to give the final assessment figure.
 
-\paragraph{Two statistical perspectives}
+\subsubsection{Two statistical perspectives}
-The Statistical Analysis method is used from two perspectives,
+he Statistical Analysis method is used from two perspectives,
 Probability of Failure on Demand (PFD), and Probability of Failure
-in continuous Operation, Failure in Time (FIT) and measured in failures per billion ($10^9$) hours of operation.
+in continuous Operation, Failure in Time (FIT).
+\paragraph{Failure in Time (FIT)}.
+
+Continuous operation is measured in failures per billion ($10^9$) hours of operation.
+For a continuously running nuclear powerstation
+we would be interested in its operational FIT values. 
+
+\paragraph{Probability of Failure on Demand (PFD)}.
 For instance with the anti-lock system on a automobile braking
 system, we would be interested in PFD.
-For a continuously running nuclear powerstation
+That is to say the ratio of it failing 
-we would be interested in its 24/7 operation FIT values. 
+to succeeding on demand.
 
+\subsubsection{FMEDA and determinability prediction accuracy}.
 This suffers from the same problems of 
 lack of determinability prediction accuracy, as FMEA above.
 %
 We have to decide how particular components failing will impact on the SYSTEM or top level.
 This involves a `leap of faith'. For instance, a resistor failing in a sensor circuit
-may be part of a critical monitioring function. 
+may be part of a critical monitoring function. 
 The analyst is now put in a position
 where he must assign a critical failure possibility to it.  
 %
@@ -361,10 +373,10 @@ of how that resistor would/could  affect that circuit, but because the circuitry
 it is part of critical section it will be linked to a critical system level fault.
 %
 A $\beta$ factor, the hueristically defined probability
-of the failure causign the system fault may be applied.
+of the failure causing the system fault may be applied.
 %
 But because there is no detailed analysis of the failure mode behaviour
-of the component, traceable to the SYSTEM level, it becomnes more
+of the component, traceable to the SYSTEM level, it becomes more
 guess work than science.
 With FMEDA, there is no rigorous cause and effect analysis for the failure modes. Unintended side
 effects that lead to failure can be missed.
@@ -401,6 +413,10 @@ for its results.
 \item It should be capable of producing reliability and danger evaluation statistics.
 \item It should be easy to use, Ideally using a graphical syntax (as oppossed to a formal mathematical one).
 \item From the top down, the failure mode model should follow a logical de-composition of the functionality
+for its results.
+\item It should be capable of producing reliability and danger evaluation statistics.
+\item It should be easy to use, ideally using a graphical syntax (as oppossed to a formal mathematical one).
+\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}.
 \item Multiple failure modes may be modelled from the base component level up.
 \end{itemize}
@@ -408,7 +424,7 @@ to smaller and smaller functional modules \cite{maikowski}.
 
 \section{Design of a new static failure mode based methodology}
 
-\paragraph{New methodology Must be bottom-up}
+\paragraph{New methodology must be bottom-up}
 In order to ensure that all component failure modes have been covered
 the methodology will have to work from the bottom-up
 and start with the component failure modes.
@@ -418,7 +434,7 @@ The traditional fault finding, or natural fault finding
 is to work from the top down. 
 %
 On encountering a 
-fault, the symptom is first know at the top or
+fault, the symptom is first observed at the top or
 SYSTEM level. By de-composing the functionality of the faulty system and testing
 we can further de-compose the system until we find the
 faulty base level component.
@@ -428,10 +444,10 @@ Simpler and simpler functional blocks are discovered as we delve
 further into the way the system works and is built.
 
 \paragraph{Design Decision: Methodology must be bottom-up.}
-In oder to ensure that all component failure modes are handled,
+In order to ensure that all component failure modes are handled,
 this methodology must start at the bottom, with base component failure modes.
 In this way automated checking can be applied to all component failure modes
-to ensure none have been inadvertantly excluded from the process.
+to ensure none have been inadvertently excluded from the process.
 
 \paragraph{Need for a `bottom-up' system de-composition}
 There is an apparent conflict here. The natural way to 
@@ -446,7 +462,7 @@ and then taking those to form higher level
 The philosophy of top down de-compositon is very similar.
 Top down de-compositon applies functional 
 de-composition, because it seeks to break the system down
-into manageable and separatetly testable entities.
+into manageable and separately testable entities.
 A second justification for this is that the design process for a product requires both top down and bottom-up
 thinking.
 
@@ -459,17 +475,21 @@ The base components will typically have several failure modes each.
 Given a typical embedded system may have hundreds of components
 This means that we have to tie base component failure modes
 to SYSTEM level errors. This is the `possibility to miss failure mode effects
-at SYSTEM level' critism of the FTA, FMEDA and FMECA methodologies.
+at SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies.
 
 \paragraph{Design Decision: Methodolgy must reduce and collate errors at each functional group stage.}
-SYSTEMS typically have far fewer failure modes then the sum of their component failure modes.
+SYSTEMS typically have far fewer failure modes than the sum of their component failure modes.
 SYSTEM level failures may be caused by a variety of component failure modes.
 A SYSTEM level failure mode is an abstracted failure mode, in that
 it is a symptom of some lower level failure or failures.
 % ABSTRACTION
 For instance a failed resistor in a sensor at a base component level is a specific 
-failure mode. For example it could be called `RESISTOR 1 OPEN'. 
+failure mode. 
-Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract.
+%
+For example it could be called `RESISTOR 1 OPEN'. 
+Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract
+or in other words describe the effect more generally.
+%
 We might call it `READING~HIGH' perhaps. At a higher level still
 this may be called `SENSOR CHANNEL 1' fault.
 At a system level it may simply be a `SENSOR FAILURE'.
@@ -485,7 +505,7 @@ of failure modes as the abstraction level reaches the SYSTEM level.
 The next problem is how to we build a failure mode model
 that converges to a finite set of SYSTEM level failure modes.
 %
-It would be better would be to analyse the failure mode behaviour of each
+It would be better to analyse the failure mode behaviour of each
 functional group, and determine the ways in which it, rather than its
 components, can fail.
 % 
@@ -502,7 +522,7 @@ The number of symptoms of failure should be equal to or
 less than the number of component failure modes, simply because
 often there are several potential causes of failure symptoms.
 %
-When we have the the symptoms, we can start thinking of the {\fg} as a component in its own right.
+When we have the symptoms, we can start thinking of the {\fg} as a component in its own right.
 %with a simplified and reduced set of failure symptoms.
 %
 We can now create a new {\dc}, where its failure modes
@@ -544,7 +564,7 @@ an entire system. It can be considered complete when
 all failure modes from all components are handled
 and connectable to a SYSTEM level failure mode.
 
-\paragraph{Directed Acyclic Graph}. This will naturally form a DAG
+\paragraph{Directed Acyclic Graph.} This will naturally form a DAG
 meaning that for all SYSTEM failure modes, we will be able to trace
 back through the DAG to possible component failure mode causes.
 If statistical models exist for the component failure modes
@@ -573,7 +593,7 @@ We can then treat the {\fg} as a `black box' or component in its own right.
 We can now look at how the {\fg} can fail. 
 %
 Many of the component failure modes will
-cause the same failure symptoms in the {fg} failure behaviour.
+cause the same failure symptoms in the {\fg} failure behaviour.
 We can collect these failures as common symptoms.
 %
 When we have our set of symptoms, we can now create
@@ -601,8 +621,8 @@ This ensures that all component failure modes are handled.
 
 
 \subsubsection{ It should be easy to integrate mechanical, electronic and software models.}
-Because component failure modes are considered, we have a generic enitity to model.
+Because component failure modes are considered, we have a generic entity to model.
-We can describe a mecanical, electrical or software component in terms of its failure modes. 
+We can describe a mechanical, electrical or software component in terms of its failure modes. 
 %
 Because of this 
 we can model and analyse integrated electro mechanical systems, controlled by computers,
@@ -666,7 +686,7 @@ chosing {\fg}s and working bottom-up this hierarchical trait will occur as a nat
 
 \section{Conclusion}
 
-This paper provides the backgroud for the need for a new methodology for
+This paper provides the background for the need for a new methodology for
 static analysis that can span the mechanical electrical and software domains
 using a common notation.
 \vspace{60pt}

lifecycle_modelling/Makefile

@@ -1,6 +1,7 @@
 
 #
-
+#
+#
 
 paper:	paper.tex lifecycle_modelling_paper.tex
 	#latex paper.tex

lifecycle_modelling/lifecycle_modelling.tex

@@ -27,6 +27,7 @@ paper
 chapter
 }
 
+\section{discovering a `new' failure mode in a component}
 
 Give general idea of how a new failure mode can be integrated into the model.
 
@@ -36,3 +37,15 @@ How it will generally be limited to small sections of th FMMD tree.
 
 
 Give specific example, pretend a new failure mode is discovered in a SCHOTTKY diode.
+
+Often an electronic component will have a new failure mode `discovered'
+I am using as an example a diode which has an exponential relationship
+with temperature and reverse leakage current. This is
+a failure mode that would not be initially considered in a design.
+But when combined with high value resistors could give incorrect voltage readings in some circuits.
+I how the FMMD model can have this new failure mode added and what
+impact it has on the FMMD data model.
+
+\section{Discovering New Failure Mode behaviour ina {\dc}}
+
+\section{New or additional evironmental Conditions}

lifecycle_modelling/paper.tex

@@ -1,4 +1,5 @@
 
+
 \documentclass[a4paper,10pt]{article}
 \usepackage{graphicx}
 \usepackage{fancyhdr}
@@ -20,9 +21,15 @@
                                               % numbers at outer edges
 \pagenumbering{arabic}                        % Arabic page numbers hereafter
 \author{R.P.Clark}
+<<<<<<< HEAD
 \title{FMMD Lifecycle Modelling}
 \maketitle 
 \input{lifecycle_modelling}
+=======
+\title{Product Lifecycle Modelling with FMMD}
+\maketitle 
+\input{lifecycle_modelling_paper}
+>>>>>>> 53352f41d87e0db41a23770a5da443a9345b982e
 
 \bibliographystyle{plain}
 \bibliography{../vmgbibliography,../mybib}

symptom_ex_process/introduction.tex

@@ -30,7 +30,9 @@ Once a hierarchy is in place, it can be converted into a fault data model.
 From the fault data model, automatic generation
 of FTA \cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets \cite{nucfta} are possible. 
 Also statistical reliability/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced 
-automatically, where component failure mode statistics are available \cite{mil1991}.
+automatically \footnote{Where component failure mode statistics are available \cite{mil1991}}.
 %
-This chapter focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy.
+This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy. 
+We can term this stage in FMMD analysis as the `symptom extraction' process. 
+The symptom extraction or abstraction process, is the key process in creating an FMMD hierarchy.
 }

symptom_ex_process/process.tex

@@ -1,4 +1,4 @@
-
+\nocite{safeware}
 \section{Overview of  Symptom Extraction Process}
 
 % TO DO: separate these two:
@@ -33,6 +33,13 @@ Each test case must be considered in the for the case of each  applied states or
 environmental conditions that it may be exposed to. In this way all
 failure mode behaviour due to the test case conditions will be examined.
 
+As part of this analysis process, records must be kept
+detailing each test case result along with its resultant 
+{\fg} failure mode.
+This data will be kept in the model and can be used to
+examine environmentally sourced common mode failure scenarios.
+
+
 %%- A {\fg} may, in the case of an electronic circuit have
 %%- applied states. For instance test modes, shutdown or lockout modes etc.
 %%- which are inputs to the circuit.
@@ -109,7 +116,6 @@ for each test case.
 
 \pagebreak[1]
 \section{A theoretical `Derived Component' example}
-
 Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$.
 
 $$ FG = \{ C_1 , C_2 , C_3 \} $$
@@ -178,6 +184,7 @@ This can be seen as all the failure modes that can affect the failure mode group
 
 \subsection{Analysis of the functional group failure modes}
 
+\label{theoreticalsx}
 For this example we shall consider single failure modes.
 %For each of the failure modes from $fm(FG)$ we shall
 %create a test case ($g_i$). Next each test case is examined/analysed
@@ -270,6 +277,11 @@ from base level components cannot be overlooked.
 The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
 }
 %
+This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component 
+with known failure modes 
+(although at a higher level of abstraction).
+This process can be repeated using {\dcs} to build a 
+hierarchical fault~mode model.
 The newly derived component $DC$ is available for use to form higher level functional groups, and we can thus
 consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
 
@@ -277,13 +289,17 @@ consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
 
 \subsection{Defining the analysis process \\ as a function}
 
-Where $\mathcal{F}$ is the set of all sets of failure modes, and $\mathcal{DC}$ 
+Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$ 
 is the set of all derived components, we can define the symptom abstraction process thus:
 $$
 %\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent 
-\bowtie : \mathcal{F} \rightarrow \mathcal{DC} 
+\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} .
 $$
 
+Given by
+$ \bowtie ( FG ) = DC $
+as per the example in preceeding section \ref{theoreticalsx}.
+
 \paragraph{Extending $\bowtie$ to {\dcs}}
 
 It is useful to further define the $\bowtie$ function, to
@@ -293,21 +309,38 @@ This generalises the function $\bowtie$ and allows us to build
 hierarchical failure mode models.
 
 Where a {\fg} is composed of derived components, for sake of example
-where $DC_1, DC_2, DC_3 $ are {\dc}s and $DCFM$ is a set of failure modes thus 
+where $DC_1, DC_2, DC_3 $ are {\dc}s  we could collect these into a {\fg} thus
-$FG = \{ DC_1, DC_2, DC_3 \}$ and $DCFM = FM(FG)$.
+$FG_{derived} = \{ DC_1, DC_2, DC_3 \}$. 
+
+$DCFM$ is a set of failure modes from the new {\fg} $FG_{derived},$ 
+$DCFM = fm(FG_{derived})$.
 
 We can apply the symptom abstraction process $\bowtie$
-to the failure mode set $DCFM$.
+to the {\fg} comprised of derived components
+because we can obtain a failure mode set,
+(the failure mode set we have named $DCFM$).
+
+Thus we can now move up another abstaction level by applying 
+symptom abstraction/extraction to the functional group
+$FG_{derived}$ shown in equation \ref{eqn:fgderived}.
+
+\begin{equation}
+\label{eqn:fgderived}
+ \bowtie ( FG_{derived} ) = DC_{derived} 
+\end{equation}
+
 
 The case 
 where a {\fg} has been created from {\dcs} 
 using function `$\bowtie$' leads us to
-{\dc}s at a higher level of fault abstraction.
+{\dc}s at a higher level of failure mode abstraction.
+A notation will be described in the next section
+to keep track of the abstraction level of a {\dc}.
 
-$$
+%%$$
 %\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent 
-\bowtie : DCFM \rightarrow DC 
+%%\bowtie : FG_{derived} \rightarrow DC 
-$$
+%%$$
 %
 %\begin{equation}
 %  \bowtie(FG_{cfm}) = DC
@@ -315,14 +348,21 @@ $$
 %
 %or applying the function $fm$ to obtain the $FG_{cfm}$ set 
 %
-To put this in context, where FG is a functional group, sourced from base or derived components,
+%%To put this in context, where FG is a functional group, sourced from base or derived components,
-we may state the process of 
+%%we may state the process of 
-analysing the failure modes in the {\fg} and returning a {\dc} thus:
+%%analysing the failure modes in the {\fg} and returning a {\dc} thus:
-\begin{equation}
+%%\begin{equation}
-  \bowtie(fm(FG)) = DC
+%%  \bowtie((FG)) = DC
-\end{equation}
+%%\end{equation}
 
 
+In other words by analysing a functional group containing derived components
+we have a new derived component as our result. 
+This naturally
+builds a bottom-up failure mode model,
+with each iteration the model becomes more abstract will eventually reach
+the SYSTEM level.
+
 %The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour.
 %The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4}
 
@@ -334,10 +374,6 @@ analysing the failure modes in the {\fg} and returning a {\dc} thus:
 %  \caption{Deriving a new diagram}
 
 
-This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component (although at a higher level of abstraction)
-with known failure modes. 
-This process can be repeated using {\dcs} to build a 
-hierarchical fault~mode model.
 
 
 

test_rigs/Makefile

@@ -0,0 +1,20 @@
+
+#
+
+
+paper:	paper.tex test_rigs_paper.tex
+	#latex paper.tex
+	#dvipdf paper     pdflatex cannot use eps ffs
+	pdflatex paper.tex
+	mv paper.pdf test_rigs.pdf
+	okular test_rigs.pdf
+
+
+
+# Remove the need for referncing graphics in subdirectories
+#
+test_rigs_paper.tex: test_rigs.tex paper.tex
+	cat test_rigs.tex | sed 's/test_rigs\///' > test_rigs_paper.tex
+
+bib:	
+	bibtex paper

test_rigs/paper.tex

@@ -0,0 +1,31 @@
+
+\documentclass[a4paper,10pt]{article}
+\usepackage{graphicx}
+\usepackage{fancyhdr}
+\usepackage{tikz}
+\usepackage{amsfonts,amsmath,amsthm}
+\input{../style}
+\usepackage{ifthen}
+\newboolean{paper}
+\setboolean{paper}{true} % boolvar=true or false
+
+
+%\newtheorem{definition}{Definition:}
+
+\begin{document}
+\pagestyle{fancy}
+
+%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}}         
+%\innerfoot{{\small\bf R.P. Clark } }   
+                                              % numbers at outer edges
+\pagenumbering{arabic}                        % Arabic page numbers hereafter
+\author{R.P.Clark}
+\title{FMMD used to assist the design of production test rigs}
+\maketitle 
+\input{test_rigs_paper}
+
+\bibliographystyle{plain}
+\bibliography{../vmgbibliography,../mybib}
+
+\today
+\end{document}

test_rigs/test_rigs.tex

@@ -0,0 +1,90 @@
+
+
+
+
+\ifthenelse {\boolean{paper}}
+{
+\abstract{ 
+This paper describes how the Failure Mode Modular De-composition (FMMD) methodology 
+can be applied to the design of automated production test rigs
+analysis.
+%
+Test rigs are often used as part of the production process
+to ensure that the SYSTEM is not only operating
+correctly but also calibrated where necessary.
+%
+% WHAT IS DID
+Mention Chris Garret and Maikowqski theses : both directly relevant.
+% WHAT I FOUND
+From the FMMD data model it is possible to link 
+sub-systems under test to 
+{\dcs} determined from the FMMD process.
+Armed with this knowledge
+the tester can be pointed to the 
+likely faulty components.
+% WHY YOU WOULD WANT TO READ IT
+This feature of FMMD proides another tool in the safety engineers
+repotiore, one that can shake out difficult to find 
+component failures from a high level test result failure.
+}
+}
+{
+\paragraph{Chapter overview}
+This chapter describes how the % Failure Mode Modular De-composition (FMMD) 
+FMMD methodology 
+can be applied to the problems of 
+test rig design and construction.
+%
+
+%
+Test rigs are often used as part of the production process
+to ensure that the SYSTEM is not only operating
+correctly but also calibrated where necessary.
+%
+% WHAT IS DID
+Mention Chris Garret and Maikowqski theses : both directly relevant.
+% WHAT I FOUND
+From the FMMD data model it is possible to link 
+sub-systems under test to 
+{\dcs} determined from the FMMD process.
+Armed with this knowledge
+the tester can be pointed to the 
+likely faulty components.
+% WHY YOU WOULD WANT TO READ IT
+This feature of FMMD proides another tool in the safety engineers
+repotiore, one that can shake out difficult to find 
+component failures from a high level test result failure.
+}
+
+ 
+\section{Introduction}
+
+\ifthenelse {\boolean{paper}}
+{
+paper
+}
+{
+chapter
+}
+
+\subsection{Description of a typical `test rig'}
+
+
+Outline the fmmd process.
+
+
+Show modules 
+which would be testable by a test rig
+
+values read or logical conditions from {\dcs}
+at a mid-level.
+
+
+Trace a theoretical example and show how FMMD detects the
+possible causes of the test rig failure.
+
+
+Exlain why this would save time and money, and possibly 
+because testing is typically done in house
+reveal any unknown failure modes of {\dcs} or even base components.
+

thesis.tex

@@ -132,9 +132,15 @@
 Safety critical in that it must not overheat, and that it must alarm
 for incorrect temperature.
 
+\chapter{Modelling and Uncovering Common Mode Failures using FMMD}
+\input{common_mode/common_mode}
+
 \chapter{FMMD Used as a design aide}
 \input{fmmd_design_aide/fmmd_design_aide}
 
+\chapter{FMMD used to aid the design of production test rigs}
+\input{test_rigs/test_rigs}
+
 \chapter{FMMD use throughout product lifecycle}
 \input{lifecycle_modelling/lifecycle_modelling}