edits from Andrew fish comments 01OCT2010

fmmdset/fmmdset.tex

@@ -5,32 +5,50 @@
 \ifthenelse {\boolean{paper}}
 {
 \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 rigorous method for creating a fault effects model of a system from the bottom up  using {\bc} level fault modes.
+This paper describes 
+a methodology to analyse  
+safety critcal designs from a failure mode perspective.
+This paper concentrates on the hierarchical model: the analysis
+phases (symtom abstraction) and {\fgs} are dealt with
+in \cite{symptom_ex}.
+
+The (Failure Mode Modular De-Composition) FMMD methodology provides
+a rigorous method for creating a fault effects model of a system from the bottom up  using {\bc} level fault modes.
 Using symptom extraction, and taking {\fgs} 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.
+It provides the means to produce Minimal cut-sets, FTA diagrams and FMEDA models, from
+a data model built by the FMMD methodology.
+It has a common notation spanning mechanical, electrical and software failures,
+and incorporating them into system models. It has been designed for small safety critical embedded
+systems, but because of its modular and hierarchical nature, can be used to model larger systems.
 It is intended to be used to formally prove systems to meet EN and UL standards, including and not limited to
 EN298, EN61508, EN12067, EN230, UL1998.
 \end{abstract}
 }
 {
-This chapter describes a process for analysing safety critical systems, to formally prove how safe the
-designs and built -in safety measures are. It provides
-the rigorous method for creating a fault effects model of a system from the bottom up  using {\bc} level fault modes.
+This chapter describes the Failure Mode Modular De-Composition (FMMD)  
+methodology to analyse  
+safety critcal designs from a failure mode perspective, with emphasis on building the hierarchical model..
+%Failure Mode Modular De-Composition (FMMD)  
+FMMD provides
+a rigorous method for creating a fault effects model of a system from the bottom up  using {\bc} level fault modes.
 Using symptom extraction, and taking {\fgs} of components, a fault behaviour
 hierarchy is built, forming a fault model tree.
-From the fault model trees,
+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.
+It provides the means to produce Minimal cut-sets, FTA diagrams and FMEDA models, from
+a data model built by the FMMD methodology.
+It has a common notation spanning mechanical, electrical and software failures,
+and incorporating them into system models. It has been designed for small safety critical embedded
+systems, but because of its modular and hierarchical nature, can be used to model larger systems.
 It is intended to be used to formally prove systems to meet EN and UL standards, including and not limited to
 EN298, EN61508, EN12067, EN230, UL1998.
-
 }
  
 
@@ -40,7 +58,7 @@ EN298, EN61508, EN12067, EN230, UL1998.
 % described here, models a safety critical system from the bottom up.
 
 The purpose of the FMMD methodology is to apply formal techniques to
-the assessment of safety critical designs, aiding in identifying detected and undetected faults
+the assessment of safety critical designs, aiding in identifying detected and undetectable faults
 \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 beginning to be specified in some safety standards.\footnote{Formal methods 
 such as the Z notation appear as `highly recommended' techniques in the EN61508 standard\cite{en61508}, but
@@ -152,7 +170,7 @@ This analysis and symptom collection process is described in detail in the Sympt
 \end{itemize}
 
 \subsubsection{An algebraic notation for identifying FMMD enitities}
-Each component $C$ is a set of failure modes for the component.
+Each component $C$ holds a set of failure modes for the component.
 We can define a function $fm$ that returns the 
 set of failure modes $F$ for the component $C$.
 
@@ -169,6 +187,13 @@ defined by, where C is a component and F is a set of failure modes.
 
 $$  fm ( C ) = F $$
 
+We can use the variable name $FG$ to represent a {\fg}. A {\fg} is a collection
+of components. We thus define $FG$ as a set of components that have been chosen as members 
+of a {\fg}.
+We can overload the $fm$ function for a functional group $FG$
+where it will return all the failure modes of the components in $FG$
+
+$$ fm (FG) = F $$
 
 %$$ \mathcal{fm}(C) \rightarrow S $$
 %$$ {fm}(C) \rightarrow S $$
@@ -180,14 +205,11 @@ the abstraction level zero thus $C^0$. Should we wish to index the components
 Our base component (if first in the parts~list) could now be uniquely identified as
 $C^0_1$.
 
-A {\fg} can use the variable name $FG$. A {\fg} is a collection
-of components. We thus define $FG$ as a set of components that have been chosen as members 
-of a {\fg}.
 We can further define the abstraction level of a {\fg}.
 We can say that it is the maximum abstraction level of any of its
 components. Thus a functional group containing only base components
 would have an abstraction level zero and could be represented with a superscript of zero thus
-$FG^0$. The functional group set may also be indexed.
+`$FG^0$'. The functional group set may also be indexed.
 
 We can apply symptom abstraction to a {\fg} to find
 a set of derived failure modes. We are interested in the failure modes
@@ -213,12 +235,12 @@ An example of a simple system will illustrate this.
 
 \subsection {Example FMEA process using an FMEA diagram}
 
-Consider a simple {\fg}  $ FG^0_1 $ derived from two base components $C^0_1,C^0_2$.
+Consider a simple {\fg}  $ FG^0_1 $ comprising of two base components $C^0_1,C^0_2$.
 
 We can apply $\bowtie$ to the {\fg} $FG$ 
-and it will return a {\dc} at abstraction level 1 (with an index of 1 for completeness)
+and it will return a {\dc} at abstraction level 1 (with an index of 1 represented a as sub-script)
 
-$$ \bowtie fm(( FG^0_1 )) = C^1_1 $$
+$$ \bowtie \big( fm(( FG^0_1 )) \big)= C^1_1 $$
 
 to look at this analysis process in more detail.
 
@@ -228,28 +250,39 @@ By way of example applying ${fm}$ to obtain the failure modes $f_N$
  $$ {fm}(C^0_1) = \{ f_1, f_2 \}  $$  
  $$ {fm}(C^0_2) = \{ f_3, f_4, f_5 \}  $$  
 
-And overloading $fm$ to find the flat set of failure modes from a {\fg}
+And overloading $fm$ to find the flat set of failure modes from the {\fg} $FG^0_1$
 
- $$ {fm}{FG^0_1} =  \{ s_6, s_7, s_8 \} $$
+ $$ {fm}({FG^0_1}) =  \{ f_1, f_2, f_3, f_4, f_5  \} $$
 
 The symptom extraction process is now applied
 i.e. the analyst now considers failure modes $f_{1..5}$ in the context of the {\fg}
-and determines the failure modes of the {\fg}..
+and determines the `failure symptoms' of the {\fg}.
 The result of this process will be a set of derived failure modes.
 For this example, let these be $  \{ s_6, s_7, s_8 \} $.
 We can now create a {\dc} $C^1_1$ with this set of failure modes.
 
 Thus:
 
-$$ {fm}(C^1_1) =  \{ s_6, s_7, s_8 \} $$
+$$ \bowtie \big( {fm}(FG^0_1) \big) = C^1_1 $$
 
 
-We can represent this analysis process in a diagram see figure \ref{fig:onestage}
+and applying $fm$ to the newly derived component 
+
+$$ fm(C^1_1) =  \{ s_6, s_7, s_8 \} $$
+
+By representing this analysis process in a diagram, the hierarchical nature
+of the process is apparent, see figure \ref{fig:onestage}.
+Each $\bowtie$ analysis phase, raises the level of failure mode abstraction.
+By this we can see the failure effects becoming less specific (for instance a resistor going open)
+and more about the effect that will have on a functional system (for instance `amplifier one' failing)
+as the failure modes raise in abstraction level.
+
 \begin{figure}[h]
  \centering
  \includegraphics[width=200pt,bb=0 0 268 270]{fmmdset/onestage.jpg}
  % onestage.jpg: 268x270 pixel, 72dpi, 9.45x9.52 cm, bb=0 0 268 270
- \caption{FMMD analysis of functional group}
+ %\caption{FMMD analysis of functional group}
+ \caption{FMMD Analysis of one functional Group: Two components form a functional group, which forms a derived component}
  \label{fig:onestage}
 \end{figure}
 
@@ -279,19 +312,32 @@ 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 {\dc} $C^{1}_{{N}}$ sets to form {\fgs}. These 
+We can take this one stage further by combining the $C^{1}_{{N}}$ {\dcs} to form {\fgs}. These 
 $FG^2_{N}$ {\fgs} can be used to create $C^3_{{N}}$ {\dcs} 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
 system level fault~modes will be traceable down to part fault modes, traversing the tree
 through the lower level {\fgs} and components. 
-each SYSTEM level fault may have a number of paths through the 
+Each SYSTEM level fault may have a number of paths through the 
 tree to different low level of base component failure modes.
 In FTA\cite{nucfta}\cite{nasafta}  terminology, these paths through the tree are called `minimal cut sets'.
 
 
-A hierarchy of levels of faults becoming more abstract at each level should
-converge to a small sub-set of system level errors.
+%A hierarchy of levels of faults becoming more abstract (at each level) should
+%converge to a small sub-set of system level errors.
+In any System there are number of general failure mode conditions.
+This number will always be far smaller than the number of component 
+failure modes of all its components.
+This is because many component level failure modes
+result in the same SYSTEM level failure modes.
+
+%%-\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 {\bc} failure modes. 
+As we go up through a fault hierarchy, the 
+number of failure modes to handle, should decrease
+with each level of abstraction.
 
 This thinning out of the number of system level errors is borne out in practice;
 real time control systems often have a small number of major reportable faults (typically $ < 50$), 
@@ -305,7 +351,7 @@ 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}
+%\cite{sem}
 
 
 
@@ -319,16 +365,12 @@ create a functional group from components at different levels of failure mode ab
 %\caption{Simple Euler Diagram}
 %\end{figure}
 
-\cite{sem}
+%\cite{sem}
 
 
 
 \section {Modelling considerations}
 
-\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 {\bc} failure modes. 
 %% This is obvious but needs a proof.
 %% Also this means that we may need dummy modules so as not to violate jumping up the tree structure
 
@@ -438,7 +480,7 @@ It is useful to follow an example fault through levels of abstraction hierarchy
 %a dangerous/potentially fatal error. Again having a complete fault analysis tree will reveal these conditions.
 
 
-\subsection{An example part Fault and its subsequent \\ abstraction to system or top level}
+\subsection{An example part Fault and \\ its representation at different abstraction levels}
 
 An example of a part fault effect on the example system is given below, showing how this fault 
 manifests itself at each abstraction level.
@@ -491,8 +533,9 @@ the circuitry between the input milli-volt signal and the ADC/Microcontroller.
 On examining this we would probably measure the in circuit resistances
 and discover the faulty resistor.
 With the natural fault finding process, we have narrowed down until we came to
-the faulty component. FMMD analysis works from the bottom~up, and this is
-because it must cover all component failure modes.
+the faulty component. 
+Because FMMD analysis works from the bottom~up, 
+it is possible to check that all component failure modes have been considered in the model.
 %%
 %% END CASE STUDY
 %%
@@ -515,9 +558,11 @@ Test rigs apply a rigorous checking process to safety critical equipment before
 they can be sold, and this usually is a legal or contractural requirement, backed up by inspections
 and and an approval process.
 
-They are usually a clamp arrangement where the PCB under test is placed.
+They are usually a clamp arrangement where the PCB under test is placed over
+connection points applied by gold plated sprung pins: these rigs are commonly known
+as `beds of nails' \cite{garret} \cite{maikowski}.
 Precision and calibrated test signals are then applied to the board under test. For PCBs containing 
-microprocessor, custom test~rig software may be run on them to exercise
+microprocessors, custom test~rig software may be run on them to exercise
 active sections of the PCB (for instance to drive outputs, relays etc).
 
 The main purpose of a test rig is to prevent fault equipment from being shipped.
@@ -530,11 +575,12 @@ Having a fault causation tree would be useful for identifying which parts may be
 or simply incorrect. The test rig armed with the fault analysis tree could point to parts or combinations of parts that could be checked
 to correct the product.
 
-\subsection {Modules - re-usability}
+\subsection {{\dcs} - Modules - re-usability}
 
 In the example system in the introduction, the milli-volt amplifiers
-are the same circuit. The set of derived faults for the module may therefore
-simply be given a different index number and re-used.
+use the same electronic circuit. The set of derived failure mode model for them is therefore
+the same.
+Thus, the derived component, for the amplifiers may be re-used, with a different index number in the model..
 
 \subsection{ Multi Channel Safety Critical Systems }