tackling fmmdset

fmmdset/Makefile

@@ -15,3 +15,7 @@ paper:	paper.tex fmmdset_p.tex
 #
 fmmdset_p.tex: fmmdset.tex
 	cat fmmdset.tex | sed 's/fmmdset\///' > fmmdset_p.tex
+
+
+bib:
+	bibtex paper

fmmdset/fmmdset.tex

@@ -7,8 +7,10 @@
 \begin{abstract} 
 This paper describes a process for analysing safety critical systems, to formally prove how safe the
 designs and built -in safety measures are. It provides
-the rigourous method for creating a fault effects model of a system from the bottom up  using part level fault modes.
-From the model fault trees, 
+the rigourous method for creating a fault effects model of a system from the bottom up  using base~component level fault modes.
+Using symptom extraction, and taking functional~groups of components, a fault behaviour
+hierarchy is built, forming a fault model tree.
+From the fault model trees, 
 modular re-usable sections of safety critical systems,
 and accurate, statistical estimation for fault frequency can be derived automatically.
 It provides the means to trace the causes of dangerous detected and dangerous undetected faults.
@@ -29,10 +31,11 @@ the assessment of safety critical designs, aiding in identifying detected and un
 \footnote{Undetectable faults 
 are faults which may occur but are not self~detected, or are impossible to detect by the system}.
 Formal methods are just begining to be specified in some safety standards.\footnote{Formal methods 
-such as the Z notation appear as `highly recommended' techniques in the EN61508 standard, but
+such as the Z notation appear as `highly recommended' techniques in the EN61508 standard\cite{en61508}, but
 apply only to software currently.} However, some standards are now implying the handling of
 simultaneous faults which complicates the scenario based approvals that are 
-currently used\footnote{Standard EN298:2003 strongly implies that double simultaneeous failures must be handled.}.
+currently used\footnote{Standard EN298:2003 demands that double simultaneous failures must be handled, in the case of 
+a single dangerous fault being detected.}.
 
 % Some safety critical system assemesment criteria 
 %are statistical, and require a target failure rate per hour of operation be met \cite{EN61508}.
@@ -43,7 +46,7 @@ There are two main philosophies in assessing safety critical systems.
 One is to specify an acceptable level of dangerous faults per hour of operation\footnote{The probability of failure per hour (PFH)
 is measured in failures per 1e-9 seconds}.
 This is a statistical approach. This is the approach taken by the European safety reliability 
-standard EN61508 commonly referred to as the Safety Integrity Level (SIL)
+standard EN61508\cite{en61508}  commonly referred to as the Safety Integrity Level (SIL)
 standard.
 The second is to specify 
 that any single or double part faults cannot lead to a dangerous fault in the system under consideration.
@@ -52,7 +55,7 @@ This entails tracing the effects of all part failure modes
 %For instance, during WWII after operational research teams had analysed  data it was determined that
 % an aircraft engine that can, through one part failure cause a catastrophic failure is an unacceptable design.\cite{boffin} .
 
-Both of these methods require a complete fault analysis tree.
+Both of these methods require a complete fault behaviour model.
 The statistical method 
 requires additional Mean Time To Failure (MTTF) data for all part failure modes.
 
@@ -63,7 +66,7 @@ of system design can be modelled once, and re-used.
 %formally prove safety critical 
 %hardware designs. 
 The  FMMD method creates a hierarchy from
-part~fault~mode level up to system level. 
+base~component fault~mode level up to system level. 
 %It does this using
 %well defined stages, and processes.  
 %It allows re-use of analysed modules DOH DOH DOH
@@ -72,7 +75,7 @@ part~fault~mode level up to system level.
 %of faults occurring are 
 When a design has been analysed using this method, fault~trees may be traversed, and statistical likelihoods of failure
 and dangerous~faults can be determined from traversing the fault tree down to the MTTFs of individual parts.
-
+FMMD has a common notation for modelling mechanical, electronic and software designs and supports their integration.
 
 %Starting with individual part failure modes, to collections of %parts (modules)
 %and then to module level fault modes.
@@ -86,23 +89,25 @@ The main idea of the methodology is to build a hierarchy of fault modes from the
 level up to highest system levels. 
 
 The first stage is to choose
-parts that interact and naturally form {\em functional groups}. {Functional groups} are thus collections of base parts.
+components that interact and naturally form {\em functional groups}. {Functional groups} are thus collections of base parts.
 %These parts all have associated fault modes. A module is a set fault~modes. 
 
-From the point of view of fault analysis, we are not interested in the parts themselves, but in the ways in which they can fail.
+From the point of view of fault analysis, we are not interested in the components themselves, but in the ways in which they can fail.
 
 For this study a functional group will mean a collection of components.
 In order to determine the symptoms or failure modes of a {\em functional group}
-we need to consider all failure modes of its parts.
+we need to consider all failure modes of its components.
 By analysing the fault behaviour of a `functional group' with respect these failure modes
 we can derive a new set of possible failure modes.
 %
-This new set of faults is the set of derived faults from the module level and is thus at a higher level of 
-fault~mode abstraction. Thus we can say that the module as a whole entity can fail in a number of well defined ways.
+This new set of faults is the set of derived faults from the perspective of the functional~group, and is thus at a higher level of 
+fault~mode abstraction. Thus we can say that the functional~group as an entity, can fail in a number of well defined ways.
 
 In other words we have taken a functional group, and analysed how it can fail according to the failure modes of its parts.
-The ways in which the module can fail now becomes a new set of fault modes, the fault~modes
-being derived from the functional~group. We can now create a new `derived~component' which has
+These new failure~modes are derived failure modes.
+%The ways in which the module can fail now becomes a new set of fault modes, the fault~modes
+%being derived from the functional~group. 
+We can now create a new `derived~component' which has
 the failure symptoms of the functional~group as its set of failure modes.
 This new derived~component is at a higher failure mode abstraction
 level than the base components.
@@ -118,6 +123,8 @@ Applying the same process with derived components we can bring derived component
 together to form functional groups and create new derived components
 at a higher abstraction level.
 
+This analysis and symptom collection process is described in detail in the Symptom extraction chapter.
+
 \subsubsection { Definitions }
 
 \begin{itemize}
@@ -169,8 +176,9 @@ We can apply symptom abstraction to a functional group to find
 a set of derived failure modes. We are interested in the failure modes
 of all the components in the functional group. An analysis process
 defined by the symbol  `$\bowtie$' is applied to the functional~group.
+Using $\alpha$ to symbolise the fault abstraction level, we can state:
 
-$$ \bowtie(FG^N) \rightarrow C^{N+1} $$ 
+$$ \bowtie(FG^{\alpha}) \rightarrow C^{{\alpha}+1} $$ 
 
 The $\bowtie$ function processes each member (component) of the set $FG$ and 
 extracts all the component failure modes, which are used by the analyst to
@@ -206,12 +214,12 @@ By way of exqample applying ${FM}$ to obtain the failure modes $f_N$
 
 The analyst now considers failure modes $f_{1..5}$ in the context of the functional group.
 The result of this process will be a set of derived failure modes.
-Let these be $  \{ f_6, f_7, f_8 \} $.
+Let these be $  \{ s_6, s_7, s_8 \} $.
 We can now create a derived component $C^1_1$ with this set of failure modes.
 
 Thus:
 
-$$ {FM}(C^1_1) =  \{ f_6, f_7, f_8 \} $$
+$$ {FM}(C^1_1) =  \{ s_6, s_7, s_8 \} $$
 
 
 We can represent this analysis process in a diagram see figure \ref{fig:onestage}
@@ -249,10 +257,10 @@ We can represent this analysis process in a diagram see figure \ref{fig:onestage
 Figure \ref{fig:fmmdh} shows a hierarchy of failure mode de-composition.
 
 It can be seen that the derived fault~mode sets are higher level abstractions of the fault behaviour of the modules.
-We can take this one stage further by combining the derived component $C^{1}_{N}$ sets to form functional~groups. These 
-$FG^2_{N}$ functional~groups can be used to create $C^3_{N}$ derived components and so on.
+We can take this one stage further by combining the derived component $C^{1}_{{N}}$ sets to form functional~groups. These 
+$FG^2_{N}$ functional~groups can be used to create $C^3_{{N}}$ derived components and so on.
 At the top of the hierarchy, there will be one final (where $t$ is the 
-top level) component $C^{t}_{N}$ and {\em its fault modes, are the failure modes of the SYSTEM}. The causes for these
+top level) component $C^{t}_{{N}}$ and {\em its fault modes, are the failure modes of the SYSTEM}. The causes for these
 system level fault~modes will be traceable down to part fault modes, traversing the tree
 through the lower level functional groups and components. 
 each SYSTEM level fault may have a number of paths through the 
@@ -268,7 +276,11 @@ real time control systems often have a small number of major reportable faults (
 even though they may have accompanying diagnostic data.
 
 
-The hierarchy is of the form of a directed acyclic graph. It is permissible, for instance, to
+The FMMD hierarchy is of the form of a directed acyclic graph. 
+Each stage of analysis builds the acyclic graph by adding to the top of the tree, leaving the previous work
+unchanged, very much in the way that the source code control system git\cite{git}
+manages source code trees.
+Because of this, it is permissible, for instance, to
 create a functional group from components at different levels of failure mode abstraction.
 
 \cite{sem}
@@ -291,7 +303,7 @@ create a functional group from components at different levels of failure mode ab
 
 \section {Modelling considerations}
 
-\subsection{ Proof of number of part~failure \\ modes preserved in hierarchy build}
+\subsection{ Proof of number of component~failure \\ modes preserved in hierarchy build}
 
 Here we need to prove that if there is an abstract fault, then as it goes higher in the tree, it can only collect MORE not less
 actual part~failure modes. This is obvious but needs a proof.
@@ -469,7 +481,7 @@ because it must cover all component failure modes.
 
 Having a fault causation tree, could be used for PCB board fault finding (from the fault codes that are reported
 by the equipment). This could be used in conjunction with a database to provide 
-Production oriented FMEA\footnote{The term FMEA applied to production, is a statistical process of 
+Production oriented FMEA\footnote{The term FMEA applied to production\cite{bfmea}, is a statistical process of 
 determining the probability of the fault occurring and multiplying that by the costs incurred from the fault. 
 This quickly becomes a priority to-do list with the most costly faults at the top}
 

fmmdset/paper.tex

@@ -26,7 +26,7 @@
 \input{fmmdset_p}
 
 \bibliographystyle{plain}
-\bibliography{vmgbibliography,mybib}
+\bibliography{../vmgbibliography,../mybib}
 
 \begin{verbatim}
 $Id: paper.tex,v 1.1 2009/06/05 18:35:31 robin Exp $

logic_diagram/paper.tex

@@ -26,7 +26,7 @@
 \input{logic_diagram_paper}
 
 \bibliographystyle{plain}
-\bibliography{vmgbibliography,mybib}
+\bibliography{../mybib,../vmgbibliography}
 
 \begin{verbatim}
 $Id: paper.tex,v 1.4 2009/11/28 20:05:52 robin Exp $

mybib.bib

@@ -29,6 +29,22 @@
 }
 
 
+@BOOK{git,
+  AUTHOR =       "Jon Loeliger",
+  TITLE =        "Version Control with Git ISBN:978-0-596-52012-0",
+  PUBLISHER =      "O'Reilly Media",
+  YEAR =         "2009"
+}
+
+
+
+@BOOK{bfmea,
+  AUTHOR =       "Robin E McDermot et all",
+  TITLE =        "The Basics of FMEA ISBN: 0-527-76320-9",
+  PUBLISHER =    "Productivity",
+  YEAR =         "1996"
+}
+
 @BOOK{mil1991,
   AUTHOR =       "United~States~DOD",
   TITLE =        "Reliability Prediction of Electronic Equipment",