From e0dc16c6719f2da3387080b38ed2fb67307e3aa9 Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Wed, 2 Nov 2011 19:34:57 +0000 Subject: [PATCH] Working b4 juggling club --- Makefile | 3 +- fmmdset/fmmdset.tex | 55 +++---- opamp_circuits_C_GARRETT/opamps.tex | 231 +++++++++++++++++++++++++--- 3 files changed, 242 insertions(+), 47 deletions(-) diff --git a/Makefile b/Makefile index 4b2f2cc..7e41653 100644 --- a/Makefile +++ b/Makefile @@ -1,6 +1,5 @@ -# $Id: Makefile,v 1.7 2008/09/26 16:31:31 robin Exp $ - +PNG = pdf: pdflatex thesis diff --git a/fmmdset/fmmdset.tex b/fmmdset/fmmdset.tex index 5f77135..f57b7fa 100644 --- a/fmmdset/fmmdset.tex +++ b/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. -We can define a function $fm$ that returns the -set of failure modes $F$ for the component $C$. +Consider all components used in a given system 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 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} - -defined by, where C is a component and F is a set of failure modes. - -$$ fm ( C ) = F $$ +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 components that have been chosen as members -of a {\fg}. +of components. We thus define $FG$ as a set of chosen components defining +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 -the abstraction level zero thus $C^0$. Should we wish to index the components +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 (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_2) = \{ f_3, f_4, f_5 \} $$ + $$ {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 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 -$FG^1_{N}$ {\fgs} can be used to create $C^2_{{N}}$ {\dcs} and so on. +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. 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 diff --git a/opamp_circuits_C_GARRETT/opamps.tex b/opamp_circuits_C_GARRETT/opamps.tex index 85b792e..1cca6bf 100644 --- a/opamp_circuits_C_GARRETT/opamps.tex +++ b/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,208 @@ wihen it becomes a V2 follower). \clearpage -\section{Unintended Side Effects: A Problem for FMMD analysis} +\section{Basic Concepts Of FMMD} + + +\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}. + +This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of +fault~mode abstraction. We can now say 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 it can fail according to the failure modes of its components. +%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 {\fg}. +We can now create a new `{\dc}' which has +the failure symptoms of the {\fg} as its set of failure modes. +This new {\dc} is at a higher `failure~mode~abstraction~level' than {\bcs}. + +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. +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. + + +\paragraph{surjective constraint applied to symptom scollection} +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. +% + + + +\subsection { 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} + +\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 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$ + + +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 the 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. + +\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 -a voltage supply rail, this could have drastic consequences for other functional groups in the system we are examining. +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. \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. -Were any of these capacitors to fail $SHORT$ they could bring down the supply voltage to the other logic chips. +A good example of this, are de-coupling capacitors, often used +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$. -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. +To a power-supply, shorted capacitors on the supply rails +are a potential source of the symptom, $SUPPLY\_SHORT$. +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 +702,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 +720,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 +750,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. -The object of FMEA is to determine cause and effect: from the failure modes (the causes) to the effects (or symptoms of failure). +When performing FMEA we have a system under investigation, which will +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 +761,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 -all the paths between failure modes and components, necessary to achieve RFMEA. +We could term this complexity a reasoning distance, as it is the number of +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 +772,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 check 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}