robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

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

Browse Source
This commit is contained in:
Robin Clark 2011-11-08 18:12:23 +00:00
commit f000365cf4
4 changed files with 248 additions and 47 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

3
Makefile
View File

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

55
fmmdset/fmmdset.tex
View File

@ -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

237
opamp_circuits_C_GARRETT/opamps.tex
View File

@ -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
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 +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.
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 +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
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 +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}

BIN
related_papers_books/GESTRA_NRS_1-50-51_SIL3_EN.ppt Normal file
View File

Binary file not shown.