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

Makefile

@@ -1,6 +1,5 @@
 
-# $Id: Makefile,v 1.7 2008/09/26 16:31:31 robin Exp $
+PNG = 
-
 
 pdf:
 	pdflatex thesis

fmmdset/fmmdset.tex

@@ -209,26 +209,29 @@ 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$ has an associated  set of failure modes for the component.
+Consider all components used in a given system to exist as
-We can define a function $fm$ that returns the 
+members of a set $\mathcal{C}$.
-set of failure modes $F$ for the component $C$.
+%
+Each component $c$ has an associated  set of failure modes.
+We can define a function $fm$ that returns a 
+set of failure modes $F$ for the component $c$.
 
 Let the set of all possible components  be $\mathcal{C}$
 and let the set of all possible failure modes be $\mathcal{F}$.
 
-We can define a function $fm$
+We now define a function $fm$
-
+as
 \begin{equation}
-fm : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F}
+fm : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F}.
 \end{equation}
-
+This is defined by, where C is a component and F is a set of failure modes,
-defined by, where C is a component and F is a set of failure modes.
+$  fm ( C ) = F. $
-
-$$  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 components. We thus define $FG$ as a set of chosen components defining 
-of a {\fg}.
+a {\fg}; all functional groups we can say that
+$FG$ is a subset of the power set of all components, $ FG \in \mathcal{P} \mathcal{C}. $
+
 We can overload the $fm$ function for a functional group $FG$
 where it will return all the failure modes of the components in $FG$
 
@@ -248,11 +251,11 @@ fm : \mathcal{FG} \rightarrow \mathcal{P}\mathcal{F}.
 %$$ {fm}(C) \rightarrow S $$
 
 We can indicate the abstraction level of a component by using a superscript.
-Thus for the component $C$, where it is a `base component' we can assign it
+Thus for the component $c$, where it is a `base component' we can assign it
-the abstraction level zero thus $C^0$. Should we wish to index the components
+the abstraction level zero thus $c^0$. Should we wish to index the components
 (for example as in a product parts~list) we can use a sub-script.
 Our base component (if first in the parts~list) could now be uniquely identified as
-$C^0_1$.
+$c^0_1$.
 
 We can further define the abstraction level of a {\fg}.
 We can say that it is the maximum abstraction level of any of its
@@ -271,7 +274,7 @@ as an argument and returns a newly created {\dc}.
 The $\bowtie$ analysis, a symptom extraction process, is described in chapter \ref{chap:sympex}.
 Using $\abslevel$ to symbolise the fault abstraction level, we can now state:
 
-$$ \bowtie(FG^{\abslevel}) \rightarrow C^{{\abslevel}+1}. $$ 
+$$ \bowtie(FG^{\abslevel}) \rightarrow c^{{\abslevel}+1}. $$ 
 
 \paragraph{The symptom abstraction process in outline.} 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
@@ -297,20 +300,20 @@ An example of a simple system will illustrate this.
 
 \subsection {Theoretical Example Symptom Abstraction Process }
 
-Consider a simple {\fg}  $ FG^0_1 $ comprising of 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 represented a as sub-script)
 
-$$ \bowtie \big( fm(( FG^0_1 )) \big)= C^1_1 .$$
+$$ \bowtie \big( fm(( FG^0_1 )) \big)= c^1_1 .$$
 
 %to look at this analysis process in more detail.
 
 By way of example, applying ${fm}$ to obtain the failure modes $f_N$ 
 
 
- $$ {fm}(C^0_1) = \{ f_1, f_2 \}  $$  
+ $$ {fm}(c^0_1) = \{ f_1, f_2 \}  $$  
- $$ {fm}(C^0_2) = \{ f_3, f_4, f_5 \}  $$  
+ $$ {fm}(c^0_2) = \{ f_3, f_4, f_5 \}  $$  
 
 And overloading $fm$ to find the flat set of failure modes from the {\fg} $FG^0_1$
 
@@ -321,16 +324,16 @@ i.e. the analyst now considers failure modes $f_{1..5}$ in the context of the {\
 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.
+We can now create a {\dc} $c^1_1$ with this set of failure modes.
 
 Thus:
 
-$$ \bowtie \big( {fm}(FG^0_1) \big) = C^1_1 $$
+$$ \bowtie \big( {fm}(FG^0_1) \big) = c^1_1 $$
 
 
 and applying $fm$ to the newly derived component 
 
-$$ fm(C^1_1) =  \{ s_6, s_7, s_8 \} $$
+$$ 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}.
@@ -374,10 +377,10 @@ as the failure modes raise in abstraction level.
 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 hierarchy one stage further by combining the abstraction level 1 components (i.e. like $C^{1}_{{N}}$) to form {\fgs}. These 
+We can take this hierarchy one stage further by combining the abstraction level 1 components (i.e. like $c^{1}_{{N}}$) to form {\fgs}. These 
-$FG^1_{N}$ {\fgs} can be used to create $C^2_{{N}}$ {\dcs} and so on.
+$FG^1_{N}$ {\fgs} can be used to create $c^2_{{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
+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 

opamp_circuits_C_GARRETT/opamps.tex

@@ -18,7 +18,7 @@
 \newcommand{\bc}{\em base~component}
 \newcommand{\bcs}{\em base~components}
 \newcommand{\irl}{in~real~life}
-
+\newcommand{\abslevel}{\ensuremath{\psi}}
 
 
 %\usepackage{glossary}
@@ -483,24 +483,214 @@ wihen it becomes a V2 follower).
 
 
 \clearpage
-\section{Unintended Side Effects: A Problem for FMMD analysis}
+\section{Basic Concepts Of FMMD}
+
+
+
+\paragraph {Definitions}
+
+\begin{itemize}
+\item {\bc} - a component with a known set of unitary state failure modes. Base here mean a starting or `bought~in' component. 
+\item {\fg} -  a collection of components chosen to perform a particular task
+\item {\em symptom} - a failure mode of a functional group caused by one or more of its component failure modes.
+\item {\dc} - a new component derived from an analysed {\fg}
+\end{itemize}
+
+\paragraph{ Creating a fault hierarchy.}
+The main concept of FMMD is to build a hierarchy of failure behaviour from the {\bc}
+level up to the top, or system level, with analysis stages between each 
+transition to a higher level in the hierarchy. 
+
+The first stage is to choose
+{\bcs} that interact and naturally form {\fgs}. The initial {\fgs} are   collections of base components.
+%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 components themselves, but in the ways in which they can fail.
+
+A {\fg} is a collection of components that perform some simple task or function.
+%
+In order to determine how a  {\fg} can fail,
+we need to consider all failure modes of its components.
+%
+By analysing the fault behaviour of a `{\fg}' with respect to all its components failure modes,
+we can determine its symptoms of failure.
+%In fact we can call these
+%the symptoms of failure for the {\fg}.
+
+With these symptoms (a set of derived faults from the perspective of the {\fg}) 
+we can now state that the {\fg} (as an entity in its own right) can fail in a number of well defined ways.
+%
+In other words we have taken a {\fg}, and analysed how 
+\textbf{it} can fail according to the failure modes of its components, and then
+determined the {\fg} failure modes.
+
+\paragraph{Creating a derived component.} 
+We create a new `{\dc}' which has
+the failure symptoms of the {\fg} from which it was derived, as its set of failure modes.
+This new {\dc} is at a higher `failure~mode~abstraction~level' than {\bcs}.
+%
+\paragraph{An example of a {\dc}.}
+To give an example of this, we could look at the components that
+form, say an amplifier. We look at how all the components within it
+could fail and how that would affect the amplifier.
+%
+The ways in which the amplifier can be affected are its symptoms.
+%
+When we have determined the symptoms, we can
+create a {\dc} (called say AMP1) which has a {\em known set of failure modes} (i.e. its symptoms).
+We can now treat $AMP1$ as a pre-analysed, higher level component.
+The amplifier is an abstract concept, in terms of the components.
+The components brought together in a specific way make it an amplifier !
+
+
+%What this means is the `fault~symptoms' of the module have been derived.
+%
+%When we have determined the fault~modes at the module level these can become a set of derived faults.
+%By taking sets of derived faults (module level faults) we can combine these to form modules
+%at a higher level of fault abstraction. An entire hierarchy of fault modes can now be built in this way,
+%to represent the fault behaviour of the entire system. This can be seen as using the modules we have analysed
+%as parts, parts which may now be combined to create new functional groups, 
+%but as parts at a higher level of fault abstraction. 
+\paragraph{Building the Hierarchy.}
+Applying the same process with {\dcs} we can bring {\dcs}
+together to form functional groups and create new {\dcs}
+at even higher abstraction levels. Eventually we will have a hierarchy
+that converges to one top level {\dc}. At this stage we have a complete failure
+mode model of the system under investigation.
+ 
+
+
+
+\subsection{An algebraic notation for identifying FMMD enitities}
+Consider all `components' to exist as
+members of a set $\mathcal{C}$.
+%
+Each component $c$ has an associated  set of failure modes.
+We can define a function $fm$ that returns a 
+set of failure modes $F$, for the component $c$.
+
+Let the set of all possible components  be $\mathcal{C}$
+and let the set of all possible failure modes be $\mathcal{F}$.
+
+We now define the function $fm$
+as
+\begin{equation}
+fm : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F}.
+\end{equation}
+This is 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 chosen components defining 
+%a {\fg}; all functional groups 
+We can state that
+$FG$ is a member of the power set of all components, $ FG \in \mathcal{P} \mathcal{C}. $
+
+We can overload the $fm$ function for a functional group $FG$
+where it will return all the failure modes of the components in $FG$
+
+
+given by
+
+$$ fm (FG) = F. $$
+
+Generally, where $\mathcal{FG}$ is the set of all functional groups,
+
+\begin{equation}
+fm : \mathcal{FG} \rightarrow \mathcal{P}\mathcal{F}.
+\end{equation}
+
+
+%$$ \mathcal{fm}(C) \rightarrow S $$
+%$$ {fm}(C) \rightarrow S $$
+
+We can indicate the abstraction level of a component by using a superscript.
+Thus for the component $c$, where it is a `base component' we can assign it
+the abstraction level zero, $c^0$. Should we wish to index the components
+(for example as in a product parts~list) we can use a sub-script.
+Our base component (if first in the parts~list) could now be uniquely identified as
+$c^0_1$.
+
+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.
+
+We can apply symptom abstraction to a {\fg} to find
+its symptoms. 
+%We are interested in the failure modes
+%of all the components in the {\fg}. An analysis process
+We define the symptom abstraction process with the symbol  `$\bowtie$'.% is applied to the {\fg}.
+%
+The $\bowtie$ function takes a {\fg}
+as an argument and returns a newly created {\dc}.
+%
+%The $\bowtie$ analysis, a symptom extraction process, is described in chapter \ref{chap:sympex}.
+The symptom abstraction process must always raise the abstraction level
+for the newly created {\dc}.
+Using $\abslevel$ to symbolise the fault abstraction level, we can now state:
+
+$$ \bowtie(FG^{\abslevel}) \rightarrow c^{{\abslevel}+N} | N \ge 1. $$ 
+
+\paragraph{The symptom abstraction process in outline.} 
+The $\bowtie$ function processes each component in the {\fg} and 
+extracts all the component failure modes.
+With all the failure modes, an analyst can   
+determine how each failure mode will affect the {\fg}, and then collect common symptoms.
+A new {\dc} is created
+where its failure modes,  are the symptoms from {\fg}.
+Note that the component must have a higher abstraction level than the {\fg}
+it was derived from.
+
+
+\paragraph{Surjective constraint applied to symptom collection.}
+We can stipulate that symptom collection process is surjective.
+% i.e. $ \forall f in F $ 
+By stipulating surjection for symptom collection, we ensure
+that each component failure mode maps to at least one one symptom.
+We also ensure that all symptoms have at least one component failure
+mode (i.e. one or more failure modes that caused it).
+%
+
+\subsection{FMMD Hierarchy}
+
+By applying stages of analysis to higher and higher abstraction
+levels, we can converge to a complete failure mode model of the system under analysis.
+Because the symptom abstraction process is defined as surjective (from component failure modes to symptoms)
+the number of symptoms is guaranteed to the less than or equal to
+the number of component failure modes.
+
+In practise however, the number of symptoms greatly reduces as we traverse
+up the hierarchy.
+This is a natural process. When we have a complicated systems
+they always have a small number of system failure modes.
+
+\clearpage
+\section{Side Effects: A Problem for FMMD analysis}
 A problem with modularising according to functionality is that we can have component failures that would 
 intuitively be associated with one {\fg} that may cause unintended side effects in other
 {\fgs}.
-For instance were we to have a component that that on failing $SHORT$ could bring down 
+For instance were we to have a component that on failing $SHORT$ could bring down 
-a voltage supply rail, this could have drastic consequences for other functional groups in the system we are examining.
+a voltage supply rail, this could have drastic consequences for other 
+functional groups in the system we are examining.
 \pagebreak[3]
 \subsection{Example de-coupling capacitors in logic circuits}
 
-A good example of this are de-coupling capacitors, often used over the power supply pins of all chips in a digital logic circuit.
+A good example of this, are de-coupling capacitors, often used 
-Were any of these capacitors to fail $SHORT$ they could bring down the supply voltage to the other logic chips.
+over the power supply pins of all chips in a digital logic circuit.
+Were any of these capacitors to fail $SHORT$ they could bring down 
+the supply voltage to the other logic chips.
 
 
-To a power-supply, shorted capacitors on the supply rails are a potential source of the symptom, $SUPPLY\_SHORT$.
+To a power-supply, shorted capacitors on the supply rails 
-In a logic chip/digital circuit {\fg} open capacitors are a potential source of symptoms caused by the failure mode $INTERFERENCE$.
+are a potential source of the symptom, $SUPPLY\_SHORT$.
-So we have a `symptom' of the power-supply, and a `failure~mode' of the logic chip to consider.
+In a logic chip/digital circuit {\fg} open capacitors are a potential 
+source of symptoms caused by the failure mode $INTERFERENCE$.
+So we have a `symptom' of the power-supply, and a `failure~mode' of
+ the logic chip to consider.
 
-The FMMD solution to this is to include the de-coupling capacitors
+A possible solution to this is to include the de-coupling capacitors
 in the power-supply {\fg}.
 % decision, could they be included in both places ????
 % I think so 
@@ -518,7 +708,11 @@ but interfere with other chips in the circuit.
 There is no reason why the de-coupling capacitors could not be included {\em in the {\fg} they would intuitively be associated with as well}.
 This allows for the general principle of a component failure affecting more than one {\fg} in a circuit.
 This allows functional groups to share components where necessary.
-
+This does not break the modularity of the FMMD technique, because, as {\irl}
+one component failure may affect more than one sub-system.
+It does uncover a weakness in the FMMD methodology though.
+It could be very easy to miss the side effect and include
+the component causing the side effect into the wrong {\fg}, or only one germane {\fg}.
 \pagebreak[3]
 \subsection{{\fgs} Sharing components and Hierarchy}
 
@@ -532,7 +726,8 @@ the {\fgs} that have to use it.
 This means that most electronic components should be placed higher in an FMMD
 hierarchy than the power-supply.
 A shorted de-coupling capactitor caused a `symptom' of the power-supply, 
-and an open de-coupling capactitor can be considered a `failure~mode' of the logic chip to consider.
+and an open de-coupling capactitor should  be considered a `failure~mode' relevant to the logic chip.
+% to consider.
 
 If components can be shared between functional groups, this means that components
 must be shareable between {\fgs} at different levels in the FMMD hierarchy.
@@ -561,8 +756,10 @@ But in order to process these failure modes it must be at a higher stage in the
 % RANGE == OUTPUTS
 %
 
-When performing FMEA we have system under investigation, which will comprise of a collection of components which have associated failure modes.
+When performing FMEA we have a system under investigation, which will 
-The object of FMEA is to determine cause and effect: from the failure modes (the causes) to the effects (or symptoms of failure).
+comprise of a collection of components which have associated failure modes.
+The object of FMEA is to determine cause and effect: 
+from the failure modes (the causes) to the effects (or symptoms of failure).
 %
 To perform FMEA rigorously
 we could stipulate that every failure mode must be checked for effects
@@ -570,8 +767,9 @@ against all the components in the system.
 We could term this `rigorous~FMEA'~(RFMEA).
 The number of checks we have to make to achieve this gives an indication of the complexity of the task.
 %
-We could term this complexity a reasoning distance, as it is the sum of 
+We could term this complexity a reasoning distance, as it is the number of 
-all the paths between failure modes and components, necessary to achieve RFMEA.
+paths between failure modes and components, necessary to achieve RFMEA.
+
 
 % (except its self of course, that component is already considered to be in a failed state!).
 %
@@ -580,15 +778,16 @@ of checks to make than for a complicated larger system.
 %
 We can consider the system as a large {\fg} of components.
 We represent the number of components in the {\fg} by 
-$$ | fg | .$$
+$ | fg | .$
 
 The function $fm$ has a component as its domain and the components failure modes as its range.
-We can represent the number of failure modes in a component $c$, to be  $$ | fm(c) | .$$
+We can represent the number of failure modes in a component $c$, to be  $ | fm(c) | .$
 
 If we index all the components in the system under investigation $ c_1, c_2 \ldots c_{|fg|} $ we can express 
 the number of checks required to rigorously examine every
 failure mode against all the other components in the system.
-We can define this as a function, $RD$, with its domain as the system or {\fg}, $fg$, and
+We can define this as a function, $RD$, with its domain as the system 
+or {\fg}, $fg$, and
 its range as the number of checks to perform to satisfy a rigorous FMEA inspection.
 
 \begin{equation}