diff --git a/old_thesis/opamp_circuits_C_GARRETT/opamps.tex b/old_thesis/opamp_circuits_C_GARRETT/opamps.tex index d54633d..9a5c5eb 100644 --- a/old_thesis/opamp_circuits_C_GARRETT/opamps.tex +++ b/old_thesis/opamp_circuits_C_GARRETT/opamps.tex @@ -46,6 +46,657 @@ These are examples of the FMMD methodology being applied to some standard electr \listoffigures +\clearpage +\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. + +\begin{figure}[h] + \centering + \includegraphics[width=200pt,keepaspectratio=true]{./tree_abstraction_levels.png} + % tree_abstraction_levels.png: 495x292 pixel, 72dpi, 17.46x10.30 cm, bb=0 0 495 292 + \caption{FMMD Hierarchy showing ascending abstraction levels} + \label{fig:treeabslev} +\end{figure} + +Figure~\ref{fig:treeabslev} shows an FMMD hierarchy, where the process of creating a {\dc} from a {\fg} +is shown as a `$\bowtie$' symbol. + + +\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} +\label{eqn:fm} +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 $$ +\paragraph{Abstraction Levels of {\fgs} and {\dcs}} + + +\label{sec:indexsub} +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{Functional Groups may be indexed} +We will typically have more than one {\fg} on each level of FMMD hierarchy ( expect the top level where there will only be one) +we could index the {\fgs} with a sub-script, and can then uniquely identify them using their level and their index. +For example ${\FG}^{3}_{2}$ would be the second {\fg} at the third level of abstraction in an FMMD hierarchy. + +\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 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 be 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 complicated systems +they always have a small number of system failure modes in comparison to +the number of failure modes in its sub-systems/components.. + + +\section{Examples of Derived Component like concepts in safety literature} + +Idea stage on this section +\begin{itemize} + \item Look at OPAMP circuits, pick one (say $\mu$741) + \item examine number of components and failure modes + \item outline a proposed FMMD analysis + \item Show FMD-91 OPAMP failure modes -- compare with FMMD +\end{itemize} + +\clearpage +Two areas that cannot be automated. Choosing {\fgs} and the analysis/symptom collection process itself. + +\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 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. + + +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. + +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 + + +Because the capacitor has two potential failure modes (EN298) +this raises another issue for FMMD. A de-coupling capacitor going $OPEN$ might not be considered relevant to +a power-supply module (but there might be additional noise on its output rails). +But in {\fg} terms the power supply, now has a new symptom that of $INTERFERENCE$. + +Some logic chips are more susceptible to $INTERFERENCE$ than others. +A logic chip with de-coupling capacitor failing, may operate correctly +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} + +With electronics we need to follow the signal path to make sense of failure modes +effects on other parts of the circuit further down that path. +%{\fgs} will naturally have to be in the position of starter +A power-supply is naturally first in a signal path (or failure reasoning path). +That is to say, if the power-supply is faulty, its failure modes are likely to affect +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 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. +This hierarchy and an optionally shared de-coupling capacitor (with line highlighted in red and dashed) are shown +in figure~\ref{fig:shared_component}. + +\begin{figure} + \centering + \includegraphics[width=250pt,keepaspectratio=true]{./shared_component.png} + % shared_component.png: 729x670 pixel, 72dpi, 25.72x23.64 cm, bb=0 0 729 670 + \caption{Optionally shared Component} + \label{fig:shared_component} +\end{figure} + +\subsection{Hierarchy and structure} +By having this structure, the logic circuit element, can accept failure modes from the +power-supply (for instance these might, for the sake of example include: $NO\_POWER$, $LOW\_VOLTAGE$, $HIGH\_VOLTAGE$, $NOISE\_HF$, $NOISE\_LF$. +Our logic circuit may be able to cope with $LOW\_VOLTAGE$ and $NOISE\_LF$, but react with a serious symptom to $NOISE\_HF$ say. +But in order to process these failure modes it must be at a higher stage in the FMMD hierarchy. + +\pagebreak[4] +\section{Defining the concept of `comparison~complexity' in FMEA} + +% +% DOMAIN == INPUTS +% RANGE == OUTPUTS +% + +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 +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 `comparison~complexity', as it is the number of +paths between failure modes and components, necessary to achieve RFMEA, for a given system/functional~group. + + +% (except its self of course, that component is already considered to be in a failed state!). +% +Obviously, for a small number of components and failure modes we have a smaller number +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} $G$, by +$ | G | $ +(an indexing and sub-scripting notation to identify particular {\fgs} +within an FMMD hierarchy is given in section~\ref{sec:indexsub}). + +The function $fm$ has a component as its domain and the components failure modes as its range (see equation~\ref{eqn:fm}). +We can represent the number of potential failure modes of 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, Comparison Complexity, $CC$, 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. + +Where $\mathcal{\FG}$ represents the set of all {\fgs}, and $ \mathbb{N} $ any natural integer, $CC$ is defined by, +\begin{equation} +%$$ + CC:\mathcal{\FG} \rightarrow \mathbb{N}, +%$$ +\end{equation} + +and, where n is the number of components in the system/{\fg}, $|fm(c_i)|$ is the number of failure modes +in component ${c_i}$, is given by + +\begin{equation} +\label{eqn:CC} +%$$ + %%% when it was called reasoning distance -- 19NOV2011 -- RD(fg) = \sum_{n=1}^{|fg|} |fm(c_n)|.(|fg|-1) + CC(\FG) = (n-1) \sum_{1 \le i \le n} fm(c_i). +%$$ +\end{equation} + +This can be simplified if we can determine the total number of failure modes in the system $K$, (i.e. $ K = \sum_{n=1}^{|G|} {|fm(c_n)|}$); +equation~\ref{eqn:CC} becomes + +%$$ +\begin{equation} +\label{eqn:rd2} + CC(\FG) = K.(|\FG|-1). +\end{equation} +%$$ +%Equation~\ref{eqn:rd} can also be expressed as +% +% \begin{equation} +% \label{eqn:rd2} +% %$$ +% CC(G) = {|G|}.{|fm(c_n)|}.{(|fg|-1)} . +% %$$ +% \end{equation} +\subsection{A general formula for counting Comparison Complexity in an FMMD hierarchy} + +An FMMD Hierarchy will have reducing numbers of functional groups as we progress up the hierarchy. +In order to calculate its comparison~complexity we need to apply equation~\ref{eqn:CC} to +all {\fgs} on each level. + +We define a helper function $g$ with a domain of the level $i$ in an FMMD hierarchy $H$, and a co-domain of a set of {\fgs} (specifically all the {\fgs} on the given level), +defined by + +\begin{equation} +%$$ +g(H, i) \rightarrow \forall {\FG}^{\xi} \;where\; ({\xi} = {i}) \wedge ({\FG}^{\xi} \in H) . +%$$ +\end{equation} + +Where $L$ represents the number of levels in the FMMD hierarchy, +$|g(\xi)|$ represents the number of functional groups on the level +and $H$ represents an FMMD hierarchy, +we overload the comparison complexity thus: +%$$ +\begin{equation} + \label{eqn:gf} + CC(H) = \sum_{\xi=0}^{L} \sum_{j=1}^{|g(H,\xi)|} CC({\FG}_{j}^{\xi}). +%$$ +\end{equation} + + +\pagebreak[4] +\subsection{Complexity Comparison Examples} + +The potential divider discussed in section~\ref{potdivfmmd} has four failure modes and two components and therefore has $CC$ of 4. +$$CC(potdiv) = \sum_{n=1}^{2} |2|.(|1|) = 4 $$ + +Even considering a $fictitious$ system with just 81 components (with these components +having 3 failure modes each) we would have an $CC$ of + +$$CC(fictitious) = \sum_{n=1}^{81} |3|.(|80|) = 19440 .$$ + +Ensuring all component failure modes are checked against all other components in a system +-- applying FMEA rigorously -- could be termed +Rigorous FMEA (RFMEA). +The computational order for RFMEA would be polynomial ($O(N^2.K)$) (where $K$ is the variable number of failure modes). + +This order may be acceptable in a computational environment: However, the choosing of {\fgs} and the analysis +process are by-hand/human activities. It can be seen that it is practically impossible to achieve +RFMEA for anything but trivial systems. +% +% Next statement needs alot of justification +% +It is the authors belief that FMMD reduces the comparison complexity enough to make +rigorous checking feasible. + + +\pagebreak[4] +%\subsection{Using the concept of Complexity Comparison to compare RFMEA with FMMD} + +\begin{figure} + \centering + \includegraphics[width=400pt,keepaspectratio=true]{./three_tree.png} + % three_tree.png: 851x385 pixel, 72dpi, 30.02x13.58 cm, bb=0 0 851 385 + \caption{FMMD Hierarchy with number of components in {\fg} fixed to 3 $(|G| = 3)$ } % \wedge (|fm(c)| = 3)$} + \label{fig:three_tree} +\end{figure} + + + +\subsection{Comparing FMMD and RFMEA comparison complexity} + +Because components have variable numbers of failure modes, +and {\fgs} have variable numbers of components it is difficult to +use the general formula for comparing the number of checks to make for +RFMEA and FMMD. +If we were to create an example by fixing the number of components in a {\fg} +and the number of failure modes per component, we can derive formulae +to compare the number of checks to make from an FMMD hierarchy to RFMEA applied to +all components in a system. + +Consider $k$ to be the number of components in a {\fg} (i.e. $k=|{\FG}|$), +$f$ is the number of failure modes per component (i.e. $f=|fm(c)|$), and +$L$ to be the number of levels in the hierarchy of an FMMD analysis. +We can represent the number of failure scenarios to check in a (fixed parameter for $|{\FG}|$ and $|fm(c_i)|$) FMMD hierarchy +with equation~\ref{eqn:anscen}. + +\begin{equation} + \label{eqn:anscen} + \sum_{n=0}^{L} {k}^{n}.k.f.(k-1) +\end{equation} + +The thinking behind equation~\ref{eqn:anscen}, is that for each level of analysis -- counting down from the top -- +there are ${k}^{n}$ {\fgs} within each level; we need to apply RFMEA to each {\fg} on the level. +The number of checks to make for RFMEA is number of components $k$ multiplied by the number of failure modes $f$ +checked against the remaining components in the {\fg} $(k-1)$. + +If, for the sake of example we fix the number of components in a {\fg} to three and +the number of failure modes per component to three, an FMMD hierarchy +would look like figure~\ref{fig:three_tree}. + +\subsection{Worked Example} + +Using the diagram in figure~\ref{fig:three_tree}, we have three levels of analysis. +Starting at the top, we have a {\fg} with three derived components, each of which has +three failure modes. +Thus the number of checks to make in the top level is $3^0.3.2.3=18$. +On the level below that, we have three {\fgs} each with a +an identical number of checks, $3^1.3.2.3=56$.%{\fg} +On the level below that we have nine {\fgs}, $3^2.3.2.3=168$. +Adding these together gives $242$ checks to make to perform FMMD (i.e. RFMEA {\em{within the}} +{\fgs}). + +If we were to take the system represented in figure~\ref{fig:three_tree}, and +apply RFMEA on it as a whole system, we can use equation~\ref{eqn:CC}, +$CC(G) = \sum_{n=1}^{|G|} |fm(c_n)|.(|G|-1)$, where $|G|$ is 27, $fm(c_n)$ is 3 +and $(|G|-1)$ is 26. +This gives: +$CC(G) = \sum_{n=1}^{27} |3|.(|27|-1) = 2106$. + +In order to get general equations with which to compare RFMEA with FMMD +we can re-write equation~\ref{eqn:CC} in terms of the number of levels +in an FMMD hierarchy. +% +The number of components in the system, is number of components +in a {\fg} raised to the power of the level plus one. +Thus we re-write equation~\ref{eqn:CC} as: + + +\begin{equation} + \label{eqn:fmea_state_exp21} + \sum_{n=1}^{k^{L+1}}.(k^{L+1}-1).f \; , % \\ + %(N^2 - N).f +\end{equation} + +or + +\begin{equation} + \label{eqn:fmea_state_exp22} + k^{L+1}.(k^{L+1}-1).f \;. % \\ + %(N^2 - N).f +\end{equation} + +We can now use equation~\ref{eqn:anscen} and \ref{eqn:fmea_state_exp22} to compare (for fixed sizes of $|G|$ and $|fm(c)|$) +the two approaches, for the work required to perform rigorous checking. + + +For instance, having four levels +of FMMD analysis, with these fixed numbers, +%(in addition to the top zeroth level) +will require 81 base level components. + +$$ +%\begin{equation} + \label{eqn:fmea_state_exp22} + 3^4.(3^4-1).3 = 81.(81-1).3 = 19440 % \\ + %(N^2 - N).f +%\end{equation} +$$ + +$$ +%\begin{equation} + % \label{eqn:anscen} + \sum_{n=0}^{3} {3}^{n}.3.3.(2) = 720 +%\end{equation} +$$ + +% \subsection{Exponential squared to Exponential} +% +% can I say that ? + + + +\section{Double Simultaneous Failures} + +The probability for independent double simultaneous component failures (because we would multiply the probabilities of failure) is very low. +However, some critical systems have to consider these type of eventualities. +The burner control industry has to consider double failures, as specified in European Norm +EN298~\cite{en298}. EN298 does not specifically state that +double simultaneous failures must be considered. What it does say is that +in the event of a lockout---a condition where an error has been detected and +the equipment moves to a safe non-functioning state---no secondary failure may cause a dangerous condition. +% +This is slightly vague: there are so many possible component failures that could +cause a secondary failure, that it is very difficult not to interpret this +as meaning we have to cater for double simultaneous failures for the most critical sections +of a burner control system. +% +In practise---in the field of EN298: burner controllers---this means triple safeguards to ensure the fuel +is not allowed to flow under an error condition. This would of course leave the possibility of +other more complex double failures tricking the controller into thinking the +combustion was actually safe when it was not. +% +It would be impractical to +perform the number of checks (as the checking is time-consuming human process) required of RFMEA on a system as complex as a burner controller. + +It has been shown that, for all but trivial small systems, double failure mode checking +is impossible from a practical perspective. +FMMD can reduce the number of checks to make to achieve double simultaneous failure checking -- but by the very nature +of choosing {\fgs} we will not (in the initial stages) be cross checking all possible +combinations of double failures in all the components. + +The diagram in figure~\ref{fig:dubsim1}, uses Euler diagrams to model failure modes (as closed contours) and asterisks +to model failure mode scenarios. The failure scenario is defined by the contours that enclose it. +Consider a system which has four components $c_1 \ldots c_4$. +Consider that each of these components may fail in two ways: $a$ and $b$, i.e $fm(c_1) = fm(c_2) = \{a,b\}$. +Now consider two {\fgs}, $fg1 = \{ c_1, c_2 \}$ and $fg2 = \{ c_3, c_4 \}$. + +We list all the possible failure scenarios as $FS1 \ldots FS6$ for each functional group. +For instance $FS5$ is the result of component $c_2$ failing with failure mode $a$ and component $c_1$ failing +with failure mode $b$. We can express this as $c_2 a \cup c_1 b$. + + +\begin{figure}[h] + \centering + \includegraphics[width=300pt,keepaspectratio=true]{./dubsim1.png} + % dubsim1.png: 612x330 pixel, 72dpi, 21.59x11.64 cm, bb=0 0 612 330 + \caption{Simultaneous Failure Mode Scenarios} + \label{fig:dubsim1} +\end{figure} + + + +From figure~\ref{fig:dubsim1} we can see that the double failure modes within the {\fgs} have been examined. +How do we model the double failures that occur across the {\fgs}, for instance +$c_4 a \cup c_1 a$. +It could be argued that because functional groups are chosen for their functionality, and re-usability +that component failures in one should not affect a different {\fg}, but this is a weak argument. +Merely double checking within {\fgs} would be marginally better than +only applying it to the most obvious critical elements of a system. + +What is really required is a way that all double simultaneous failures +are checked. + +One way of doing this is to apply double failure mode +checking to all {\fgs} higher up in the hierarchy. + +This guarantees to check the symptoms caused by the +failure modes in the other {\fgs} with the symptoms +derived from the other {\fgs} modelling for double failures. +% +By traversing down the tree we can automatically determine which +double simultaneous combinations have not been resolved. +% +By applying double simultaneous checking until no single failures +canlead to a top level event, we +double failure move coverage. + +To extend the example in figure~\ref{fig:dubsim1} we can map the failure +scenarios. +For Functional Group 1 (FG1), let us map: +\begin{eqnarray*} + FS1 & \mapsto & S1 \\ + FS2 & \mapsto & S3 \\ + FS3 & \mapsto & S1 \\ + FS4 & \mapsto & S2 \\ + FS5 & \mapsto & S2 \\ + FS6 & \mapsto & S3 +\end{eqnarray*} + +Thus a derived component, DC1, has the failure modes defined by $fm(DC1) = \{ S1, S2, S3 \}$. + + +For Functional Group 2 (FG2), let us map: +\begin{eqnarray*} + FS1 & \mapsto & S4 \\ + FS2 & \mapsto & S5 \\ + FS3 & \mapsto & S5 \\ + FS4 & \mapsto & S4 \\ + FS5 & \mapsto & S6 \\ + FS6 & \mapsto & S5 +\end{eqnarray*} + +This AUTOMATIC check can reveal WHEN double checking no longer necessary +in the hierarchy to cover dub sum !!!!! YESSSS + \section{Non-Inverting OPAMP} Consider a non inverting op-amp designed to amplify a small positive voltage (typical use would be a thermocouple amplifier @@ -926,7 +1577,7 @@ returns three failure modes, $$ fm(BubbaOscillator) = \{ NO_{osc}, HI_{fosc}, LO_{fosc} \} . $$ - +\clearpage \subsection{FMMD Analysis using smaller functional groups} @@ -1096,657 +1747,6 @@ More re-use-able fgs with smaller groups. Less chance of making a mistake (lower -\clearpage -\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. - -\begin{figure}[h] - \centering - \includegraphics[width=200pt,keepaspectratio=true]{./tree_abstraction_levels.png} - % tree_abstraction_levels.png: 495x292 pixel, 72dpi, 17.46x10.30 cm, bb=0 0 495 292 - \caption{FMMD Hierarchy showing ascending abstraction levels} - \label{fig:treeabslev} -\end{figure} - -Figure~\ref{fig:treeabslev} shows an FMMD hierarchy, where the process of creating a {\dc} from a {\fg} -is shown as a `$\bowtie$' symbol. - - -\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} -\label{eqn:fm} -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 $$ -\paragraph{Abstraction Levels of {\fgs} and {\dcs}} - - -\label{sec:indexsub} -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{Functional Groups may be indexed} -We will typically have more than one {\fg} on each level of FMMD hierarchy ( expect the top level where there will only be one) -we could index the {\fgs} with a sub-script, and can then uniquely identify them using their level and their index. -For example ${\FG}^{3}_{2}$ would be the second {\fg} at the third level of abstraction in an FMMD hierarchy. - -\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 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 be 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 complicated systems -they always have a small number of system failure modes in comparison to -the number of failure modes in its sub-systems/components.. - - -\section{Examples of Derived Component like concepts in safety literature} - -Idea stage on this section -\begin{itemize} - \item Look at OPAMP circuits, pick one (say $\mu$741) - \item examine number of components and failure modes - \item outline a proposed FMMD analysis - \item Show FMD-91 OPAMP failure modes -- compare with FMMD -\end{itemize} - -\clearpage -Two areas that cannot be automated. Choosing {\fgs} and the analysis/symptom collection process itself. - -\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 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. - - -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. - -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 - - -Because the capacitor has two potential failure modes (EN298) -this raises another issue for FMMD. A de-coupling capacitor going $OPEN$ might not be considered relevant to -a power-supply module (but there might be additional noise on its output rails). -But in {\fg} terms the power supply, now has a new symptom that of $INTERFERENCE$. - -Some logic chips are more susceptible to $INTERFERENCE$ than others. -A logic chip with de-coupling capacitor failing, may operate correctly -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} - -With electronics we need to follow the signal path to make sense of failure modes -effects on other parts of the circuit further down that path. -%{\fgs} will naturally have to be in the position of starter -A power-supply is naturally first in a signal path (or failure reasoning path). -That is to say, if the power-supply is faulty, its failure modes are likely to affect -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 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. -This hierarchy and an optionally shared de-coupling capacitor (with line highlighted in red and dashed) are shown -in figure~\ref{fig:shared_component}. - -\begin{figure} - \centering - \includegraphics[width=250pt,keepaspectratio=true]{./shared_component.png} - % shared_component.png: 729x670 pixel, 72dpi, 25.72x23.64 cm, bb=0 0 729 670 - \caption{Optionally shared Component} - \label{fig:shared_component} -\end{figure} - -\subsection{Hierarchy and structure} -By having this structure, the logic circuit element, can accept failure modes from the -power-supply (for instance these might, for the sake of example include: $NO\_POWER$, $LOW\_VOLTAGE$, $HIGH\_VOLTAGE$, $NOISE\_HF$, $NOISE\_LF$. -Our logic circuit may be able to cope with $LOW\_VOLTAGE$ and $NOISE\_LF$, but react with a serious symptom to $NOISE\_HF$ say. -But in order to process these failure modes it must be at a higher stage in the FMMD hierarchy. - -\pagebreak[4] -\section{Defining the concept of `comparison~complexity' in FMEA} - -% -% DOMAIN == INPUTS -% RANGE == OUTPUTS -% - -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 -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 `comparison~complexity', as it is the number of -paths between failure modes and components, necessary to achieve RFMEA, for a given system/functional~group. - - -% (except its self of course, that component is already considered to be in a failed state!). -% -Obviously, for a small number of components and failure modes we have a smaller number -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} $G$, by -$ | G | $ -(an indexing and sub-scripting notation to identify particular {\fgs} -within an FMMD hierarchy is given in section~\ref{sec:indexsub}). - -The function $fm$ has a component as its domain and the components failure modes as its range (see equation~\ref{eqn:fm}). -We can represent the number of potential failure modes of 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, Comparison Complexity, $CC$, 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. - -Where $\mathcal{\FG}$ represents the set of all {\fgs}, and $ \mathbb{N} $ any natural integer, $CC$ is defined by, -\begin{equation} -%$$ - CC:\mathcal{\FG} \rightarrow \mathbb{N}, -%$$ -\end{equation} - -and, where n is the number of components in the system/{\fg}, $|fm(c_i)|$ is the number of failure modes -in component ${c_i}$, is given by - -\begin{equation} -\label{eqn:CC} -%$$ - %%% when it was called reasoning distance -- 19NOV2011 -- RD(fg) = \sum_{n=1}^{|fg|} |fm(c_n)|.(|fg|-1) - CC(\FG) = (n-1) \sum_{1 \le i \le n} fm(c_i). -%$$ -\end{equation} - -This can be simplified if we can determine the total number of failure modes in the system $K$, (i.e. $ K = \sum_{n=1}^{|G|} {|fm(c_n)|}$); -equation~\ref{eqn:CC} becomes - -%$$ -\begin{equation} -\label{eqn:rd2} - CC(\FG) = K.(|\FG|-1). -\end{equation} -%$$ -%Equation~\ref{eqn:rd} can also be expressed as -% -% \begin{equation} -% \label{eqn:rd2} -% %$$ -% CC(G) = {|G|}.{|fm(c_n)|}.{(|fg|-1)} . -% %$$ -% \end{equation} -\subsection{A general formula for counting Comparison Complexity in an FMMD hierarchy} - -An FMMD Hierarchy will have reducing numbers of functional groups as we progress up the hierarchy. -In order to calculate its comparison~complexity we need to apply equation~\ref{eqn:CC} to -all {\fgs} on each level. - -We define a helper function $g$ with a domain of the level $i$ in an FMMD hierarchy $H$, and a co-domain of a set of {\fgs} (specifically all the {\fgs} on the given level), -defined by - -\begin{equation} -%$$ -g(H, i) \rightarrow \forall {\FG}^{\xi} \;where\; ({\xi} = {i}) \wedge ({\FG}^{\xi} \in H) . -%$$ -\end{equation} - -Where $L$ represents the number of levels in the FMMD hierarchy, -$|g(\xi)|$ represents the number of functional groups on the level -and $H$ represents an FMMD hierarchy, -we overload the comparison complexity thus: -%$$ -\begin{equation} - \label{eqn:gf} - CC(H) = \sum_{\xi=0}^{L} \sum_{j=1}^{|g(H,\xi)|} CC({\FG}_{j}^{\xi}). -%$$ -\end{equation} - - -\pagebreak[4] -\subsection{Complexity Comparison Examples} - -The potential divider discussed in section~\ref{potdivfmmd} has four failure modes and two components and therefore has $CC$ of 4. -$$CC(potdiv) = \sum_{n=1}^{2} |2|.(|1|) = 4 $$ - -Even considering a $fictitious$ system with just 81 components (with these components -having 3 failure modes each) we would have an $CC$ of - -$$CC(fictitious) = \sum_{n=1}^{81} |3|.(|80|) = 19440 .$$ - -Ensuring all component failure modes are checked against all other components in a system --- applying FMEA rigorously -- could be termed -Rigorous FMEA (RFMEA). -The computational order for RFMEA would be polynomial ($O(N^2.K)$) (where $K$ is the variable number of failure modes). - -This order may be acceptable in a computational environment: However, the choosing of {\fgs} and the analysis -process are by-hand/human activities. It can be seen that it is practically impossible to achieve -RFMEA for anything but trivial systems. -% -% Next statement needs alot of justification -% -It is the authors belief that FMMD reduces the comparison complexity enough to make -rigorous checking feasible. - - -\pagebreak[4] -%\subsection{Using the concept of Complexity Comparison to compare RFMEA with FMMD} - -\begin{figure} - \centering - \includegraphics[width=400pt,keepaspectratio=true]{./three_tree.png} - % three_tree.png: 851x385 pixel, 72dpi, 30.02x13.58 cm, bb=0 0 851 385 - \caption{FMMD Hierarchy with number of components in {\fg} fixed to 3 $(|G| = 3)$ } % \wedge (|fm(c)| = 3)$} - \label{fig:three_tree} -\end{figure} - - - -\subsection{Comparing FMMD and RFMEA comparison complexity} - -Because components have variable numbers of failure modes, -and {\fgs} have variable numbers of components it is difficult to -use the general formula for comparing the number of checks to make for -RFMEA and FMMD. -If we were to create an example by fixing the number of components in a {\fg} -and the number of failure modes per component, we can derive formulae -to compare the number of checks to make from an FMMD hierarchy to RFMEA applied to -all components in a system. - -Consider $k$ to be the number of components in a {\fg} (i.e. $k=|{\FG}|$), -$f$ is the number of failure modes per component (i.e. $f=|fm(c)|$), and -$L$ to be the number of levels in the hierarchy of an FMMD analysis. -We can represent the number of failure scenarios to check in a (fixed parameter for $|{\FG}|$ and $|fm(c_i)|$) FMMD hierarchy -with equation~\ref{eqn:anscen}. - -\begin{equation} - \label{eqn:anscen} - \sum_{n=0}^{L} {k}^{n}.k.f.(k-1) -\end{equation} - -The thinking behind equation~\ref{eqn:anscen}, is that for each level of analysis -- counting down from the top -- -there are ${k}^{n}$ {\fgs} within each level; we need to apply RFMEA to each {\fg} on the level. -The number of checks to make for RFMEA is number of components $k$ multiplied by the number of failure modes $f$ -checked against the remaining components in the {\fg} $(k-1)$. - -If, for the sake of example we fix the number of components in a {\fg} to three and -the number of failure modes per component to three, an FMMD hierarchy -would look like figure~\ref{fig:three_tree}. - -\subsection{Worked Example} - -Using the diagram in figure~\ref{fig:three_tree}, we have three levels of analysis. -Starting at the top, we have a {\fg} with three derived components, each of which has -three failure modes. -Thus the number of checks to make in the top level is $3^0.3.2.3=18$. -On the level below that, we have three {\fgs} each with a -an identical number of checks, $3^1.3.2.3=56$.%{\fg} -On the level below that we have nine {\fgs}, $3^2.3.2.3=168$. -Adding these together gives $242$ checks to make to perform FMMD (i.e. RFMEA {\em{within the}} -{\fgs}). - -If we were to take the system represented in figure~\ref{fig:three_tree}, and -apply RFMEA on it as a whole system, we can use equation~\ref{eqn:CC}, -$CC(G) = \sum_{n=1}^{|G|} |fm(c_n)|.(|G|-1)$, where $|G|$ is 27, $fm(c_n)$ is 3 -and $(|G|-1)$ is 26. -This gives: -$CC(G) = \sum_{n=1}^{27} |3|.(|27|-1) = 2106$. - -In order to get general equations with which to compare RFMEA with FMMD -we can re-write equation~\ref{eqn:CC} in terms of the number of levels -in an FMMD hierarchy. -% -The number of components in the system, is number of components -in a {\fg} raised to the power of the level plus one. -Thus we re-write equation~\ref{eqn:CC} as: - - -\begin{equation} - \label{eqn:fmea_state_exp21} - \sum_{n=1}^{k^{L+1}}.(k^{L+1}-1).f \; , % \\ - %(N^2 - N).f -\end{equation} - -or - -\begin{equation} - \label{eqn:fmea_state_exp22} - k^{L+1}.(k^{L+1}-1).f \;. % \\ - %(N^2 - N).f -\end{equation} - -We can now use equation~\ref{eqn:anscen} and \ref{eqn:fmea_state_exp22} to compare (for fixed sizes of $|G|$ and $|fm(c)|$) -the two approaches, for the work required to perform rigorous checking. - - -For instance, having four levels -of FMMD analysis, with these fixed numbers, -%(in addition to the top zeroth level) -will require 81 base level components. - -$$ -%\begin{equation} - \label{eqn:fmea_state_exp22} - 3^4.(3^4-1).3 = 81.(81-1).3 = 19440 % \\ - %(N^2 - N).f -%\end{equation} -$$ - -$$ -%\begin{equation} - % \label{eqn:anscen} - \sum_{n=0}^{3} {3}^{n}.3.3.(2) = 720 -%\end{equation} -$$ - -% \subsection{Exponential squared to Exponential} -% -% can I say that ? - - - -\section{Double Simultaneous Failures} - -The probability for independent double simultaneous component failures (because we would multiply the probabilities of failure) is very low. -However, some critical systems have to consider these type of eventualities. -The burner control industry has to consider double failures, as specified in European Norm -EN298~\cite{en298}. EN298 does not specifically state that -double simultaneous failures must be considered. What it does say is that -in the event of a lockout---a condition where an error has been detected and -the equipment moves to a safe non-functioning state---no secondary failure may cause a dangerous condition. -% -This is slightly vague: there are so many possible component failures that could -cause a secondary failure, that it is very difficult not to interpret this -as meaning we have to cater for double simultaneous failures for the most critical sections -of a burner control system. -% -In practise---in the field of EN298: burner controllers---this means triple safeguards to ensure the fuel -is not allowed to flow under an error condition. This would of course leave the possibility of -other more complex double failures tricking the controller into thinking the -combustion was actually safe when it was not. -% -It would be impractical to -perform the number of checks (as the checking is time-consuming human process) required of RFMEA on a system as complex as a burner controller. - -It has been shown that, for all but trivial small systems, double failure mode checking -is impossible from a practical perspective. -FMMD can reduce the number of checks to make to achieve double simultaneous failure checking -- but by the very nature -of choosing {\fgs} we will not (in the initial stages) be cross checking all possible -combinations of double failures in all the components. - -The diagram in figure~\ref{fig:dubsim1}, uses Euler diagrams to model failure modes (as closed contours) and asterisks -to model failure mode scenarios. The failure scenario is defined by the contours that enclose it. -Consider a system which has four components $c_1 \ldots c_4$. -Consider that each of these components may fail in two ways: $a$ and $b$, i.e $fm(c_1) = fm(c_2) = \{a,b\}$. -Now consider two {\fgs}, $fg1 = \{ c_1, c_2 \}$ and $fg2 = \{ c_3, c_4 \}$. - -We list all the possible failure scenarios as $FS1 \ldots FS6$ for each functional group. -For instance $FS5$ is the result of component $c_2$ failing with failure mode $a$ and component $c_1$ failing -with failure mode $b$. We can express this as $c_2 a \cup c_1 b$. - - -\begin{figure}[h] - \centering - \includegraphics[width=300pt,keepaspectratio=true]{./dubsim1.png} - % dubsim1.png: 612x330 pixel, 72dpi, 21.59x11.64 cm, bb=0 0 612 330 - \caption{Simultaneous Failure Mode Scenarios} - \label{fig:dubsim1} -\end{figure} - - - -From figure~\ref{fig:dubsim1} we can see that the double failure modes within the {\fgs} have been examined. -How do we model the double failures that occur across the {\fgs}, for instance -$c_4 a \cup c_1 a$. -It could be argued that because functional groups are chosen for their functionality, and re-usability -that component failures in one should not affect a different {\fg}, but this is a weak argument. -Merely double checking within {\fgs} would be marginally better than -only applying it to the most obvious critical elements of a system. - -What is really required is a way that all double simultaneous failures -are checked. - -One way of doing this is to apply double failure mode -checking to all {\fgs} higher up in the hierarchy. - -This guarantees to check the symptoms caused by the -failure modes in the other {\fgs} with the symptoms -derived from the other {\fgs} modelling for double failures. -% -By traversing down the tree we can automatically determine which -double simultaneous combinations have not been resolved. -% -By applying double simultaneous checking until no single failures -canlead to a top level event, we -double failure move coverage. - -To extend the example in figure~\ref{fig:dubsim1} we can map the failure -scenarios. -For Functional Group 1 (FG1), let us map: -\begin{eqnarray*} - FS1 & \mapsto & S1 \\ - FS2 & \mapsto & S3 \\ - FS3 & \mapsto & S1 \\ - FS4 & \mapsto & S2 \\ - FS5 & \mapsto & S2 \\ - FS6 & \mapsto & S3 -\end{eqnarray*} - -Thus a derived component, DC1, has the failure modes defined by $fm(DC1) = \{ S1, S2, S3 \}$. - - -For Functional Group 2 (FG2), let us map: -\begin{eqnarray*} - FS1 & \mapsto & S4 \\ - FS2 & \mapsto & S5 \\ - FS3 & \mapsto & S5 \\ - FS4 & \mapsto & S4 \\ - FS5 & \mapsto & S6 \\ - FS6 & \mapsto & S5 -\end{eqnarray*} - -This AUTOMATIC check can reveal WHEN double checking no longer necessary -in the hierarchy to cover dub sum !!!!! YESSSS - % does not cover what weird side effect may occur though, but then the {\fg} was not modelled correctly in the first place...