1472 lines
60 KiB
TeX
1472 lines
60 KiB
TeX
%%
|
|
%% CHAPTER 4 : Failure Mode Modular Discrimination
|
|
%%
|
|
\label{sec:chap4}
|
|
% \ifthenelse {\boolean{paper}}
|
|
% {
|
|
% \abstract{
|
|
% This paper defines %what is meant by
|
|
% the terms
|
|
% components, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes.
|
|
% %The application of Bayes theorem in current methodologies, and
|
|
% %the suitability of the `null hypothesis' or `P' value statistical approach
|
|
% %are discussed.
|
|
% The general concept of the cardinality constrained powerset is introduced
|
|
% and calculations for it described, and then for
|
|
% calculations under `unitary state' fault mode conditions.
|
|
% Data types and their relationships are described using UML.
|
|
% Mathematical constraints and definitions are made using set theory.}
|
|
% }
|
|
% {
|
|
% \section{Overview}
|
|
% This chapter defines the FMMD process and related concepts and calculations.
|
|
% FMMD is in essence modularised FMEA. Rather than taking each component failure mode
|
|
% and extrapolating top level or system failure symptoms from it,
|
|
% small groups of components are collected into {\fgs} and analysed,
|
|
% and then {\dcs} are used to represent the {\fgs}.
|
|
% These {\dcs} are used to then build further {\fgs} until a hierarchy of {\fgs}
|
|
% and {\dcs} has been built, converging to a final {\dc}
|
|
% at the top of the hierarchy.
|
|
%
|
|
% Or in other words we take the traditional FMEA process, and modularise it.
|
|
% We break down each stage of reasoning
|
|
% into small manageable groups, and use the results of those groups, as {\dcs}
|
|
% to build higher level groups.
|
|
% %This has advantages of concentrating
|
|
% %effort in where modules interact,
|
|
|
|
|
|
%% J. Howse 04MAY2012 REMOVEFirstly, %what is meant by
|
|
%% J. Howse 04MAY2012 REMOVEthe terms
|
|
%% J. Howse 04MAY2012 REMOVEcomponents, failure~modes, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes are defined.
|
|
%
|
|
%% J. Howse 04MAY2012 REMOVE The general concept of the cardinality constrained powerset is introduced
|
|
%% J. Howse 04MAY2012 REMOVE and calculations for it described, and performance
|
|
%% J. Howse 04MAY2012 REMOVE calculations (comparing traditional FMEA and FMMD)
|
|
%% J. Howse 04MAY2012 REMOVE are presented. % under `unitary state' fault mode conditions.
|
|
%
|
|
%% J. Howse 04MAY2012 REMOVEData types and their relationships are described using UML.
|
|
%% J. Howse 04MAY2012 REMOVEMathematical constraints and definitions are made using set theory.
|
|
% }
|
|
|
|
|
|
\section{Introduction}
|
|
This chapter
|
|
starts with %starts with %an overview of current failure modelling techniques, and then
|
|
a worked example to introduce % using
|
|
a new methodology,
|
|
Failure Mode Modular De-composition (FMMD).
|
|
This is followed by a discussion on the design of FMMD, a
|
|
%an ontological
|
|
description of the FMMD process and finally the
|
|
data structures required using UML class models.
|
|
|
|
% This chapter defines the FMMD process and related concepts and calculations.
|
|
FMMD is in essence a modularised variant of traditional FMEA~\cite{sccs}[pp.34-38].
|
|
\fmmdgloss
|
|
%
|
|
%FMEA is a bottom-up, or forward search failure mode technique starting with
|
|
%base component failure modes~\cite{safeware}[p.341].
|
|
%
|
|
%\subsection{FMMD Process in outline.}
|
|
%
|
|
In order to analyse from the bottom-up and apply a modular methodology, we need to take
|
|
small groups of components that naturally
|
|
work together to perform a simple function: we term these groups `{\fgs}'.
|
|
%
|
|
\fmmdglossFG
|
|
%
|
|
The components to include in a {\fg} are chosen by hand.
|
|
%a human, the analyst.
|
|
%We can represent the `Functional~Group' as a class.
|
|
When we have a
|
|
{\fg} we can look at the components it contains,
|
|
and from this determine the failure modes of all the components that belong to it.
|
|
%
|
|
%Initial {\fgs} will consist of {\bcs}.
|
|
%
|
|
% and determine a failure mode model for that group.
|
|
%
|
|
% expand 21sep2010
|
|
%The `{\fg}' as used by the analyst is a collection of component failures modes.
|
|
%The analysts interest is in the ways in which the components within the {\fg}
|
|
%can fail.
|
|
%
|
|
All the failure modes of all the components within a {\fg} are collected.
|
|
%
|
|
%As each component %mode holds
|
|
%has a set of failure modes associated with it,
|
|
%the {\fg} represents a set of sets of failure modes.
|
|
%
|
|
%We convert this
|
|
%into a flat set
|
|
%of failure modes for use in analysis.
|
|
%
|
|
%A flat set is a set containing just the failure modes and not sets of failure modes~\cite{joyofsets}[p.8].
|
|
%
|
|
Each component failure mode can considered as a `failure~scenario' or 'test~case'
|
|
applied to a {\fg}.
|
|
%
|
|
Each of these failure modes, and optionally combinations of them, are
|
|
formed into test~cases which
|
|
are analysed for their effect on the failure mode behaviour of the `{\fg}'.
|
|
%
|
|
Once we have the failure mode behaviour of the {\fg}, we can determine its symptoms of failure.
|
|
%,
|
|
%or the failure modes of the {\dc}.
|
|
%for the {\fg}.
|
|
%
|
|
We view these symptoms as the %derived
|
|
failure modes of the {\fg}.
|
|
%
|
|
\fmmdglossFG
|
|
\fmmdglossSYMPTOM
|
|
%Or in other words
|
|
That is, we can determine how the {\fg} can fail.
|
|
As we now have a set of failure modes for the {\fg} we can treat it as a component.
|
|
We can now consider the {\fg} as a `{\dc}' % sort of super component
|
|
with its own set of failure modes.
|
|
%
|
|
\fmmdglossDC
|
|
% Rather than taking each component failure mode
|
|
% and extrapolating top level or system failure symptoms from it,
|
|
% small groups of components are collected into {\fgs} and analysed.
|
|
%
|
|
%
|
|
% %and then {\dcs} are used to represent the {\fgs}.
|
|
% We analyse each {\fg} in order to determine its failure mode behaviour.
|
|
% %of the {\fg}.
|
|
% With the failure mode behaviour we can obtain a set of failure modes
|
|
% for the {\fg}.
|
|
% %
|
|
% Or in other words we determine how the {\fg}, as an entity can fail.
|
|
% %
|
|
% We can then create a new theoretical component to represent the {\fg}.
|
|
% %
|
|
% We call this a {\dc}.
|
|
% %
|
|
%We term this newly created component as a `{dc}'.
|
|
%This {\dc} has a set of failure modes: we can thus treat it as a `higher~level' component.
|
|
%
|
|
Because a {\dc} has a set of failure modes we can use it in higher level {\fgs}
|
|
which in turn produce higher level {\dcs}.
|
|
%
|
|
We can then use these {\dcs} to build further {\fgs} until a hierarchy of {\fgs}
|
|
and {\dcs} has been built, converging to a final {\dc}
|
|
at the top of the hierarchy.
|
|
%
|
|
The failure modes of the final or top {\dc}
|
|
are the failure modes of the system under investigation.
|
|
%
|
|
That is, we take the traditional FMEA process and modularise it from the bottom-up.
|
|
%We break down each stage of reasoning
|
|
%into small manageable groups, and use the failure mode behaviour from them to create {\dcs}
|
|
%to build higher level groups.
|
|
In this way we can incrementally apply FMEA to an entire system. %, with documented reasoning stages.
|
|
\fmmdglossDC
|
|
\fmmdgloss
|
|
%
|
|
This has advantages of concentrating
|
|
effort in where modules interact (interfaces), of
|
|
being able to re-use work and savings in the complexity of performing
|
|
FMEA (because the analysis is typically performed in several small stages
|
|
thus avoiding state explosion).
|
|
%A notation is then described to index and classify objects created in FMMD hierarchical models.
|
|
\fmmdglossSTATEEX
|
|
|
|
|
|
\section{Worked Example: Non-Inverting Amplifier}
|
|
\label{sec:noninvamp}
|
|
%% here bring in sys safety paper from 2011
|
|
%%
|
|
%% GARK BEGIN
|
|
|
|
We demonstrate the principles of FMMD, by using it to analyse a
|
|
commonly used circuit, a non-inverting amplifier built from an op amp~\cite{aoe}[p.234] and
|
|
two resistors; a circuit schematic for this is shown in figure \ref{fig:noninvamp}.
|
|
%
|
|
\begin{figure}[h+]
|
|
\centering
|
|
%\includegraphics[width=100pt,keepaspectratio=true]{../../noninvopamp/noninv.png}
|
|
\includegraphics[width=300pt,keepaspectratio=true]{./CH4_FMMD/noninv.png}
|
|
% noninv.jpg: 341x186 pixel, 72dpi, 12.03x6.56 cm, bb=0 0 341 186
|
|
\caption{Standard non inverting amplifier configuration}
|
|
\label{fig:noninvamp}
|
|
\end{figure}
|
|
%
|
|
The function of the resistors in this circuit is to set the amplifier gain.
|
|
%
|
|
The resistors act as a potential divider---assuming the op-amp has high impedance---and
|
|
program the inverting input on the op-amp
|
|
to balance them against the positive input, giving the voltage gain ($G_v$)
|
|
defined by $ G_v = 1 + \frac{R2}{R1} $ at the output.
|
|
|
|
|
|
\paragraph{Analysing the failure modes of the Potential Divider.}
|
|
\label{subsec:potdiv}
|
|
Since the resistors work to provide a clearly defined function, that of a potential divider,
|
|
we can treat them as a collection of components with a specific functionality---i.e. a `{\fg}'.
|
|
This {\fg} has two members, $R1$ and $R2$.
|
|
%
|
|
The potential divider circuit can be considered as a component
|
|
that provides the function of splitting two voltages into three,
|
|
the third voltage being a ratio defined by the values of the resistors.
|
|
%Taken as an entity the potential divider can be viewed as a {\dc}.
|
|
%That is to say we can treat the potential divider, comprised of two resistors
|
|
%to act as a {\dc}.
|
|
%
|
|
Using the EN298 specification for resistor failure~\cite{en298}[App.A],
|
|
we can assign failure modes of $OPEN$ and $SHORT$ to the resistors individually (assignment of failure modes
|
|
is discussed in more detail in section~\ref{sec:resistorfm}).
|
|
%
|
|
We represent a resistor and its failure modes as a directed acyclic graph (DAG)
|
|
(see figure \ref{fig:rdag}).
|
|
\begin{figure}[h+]
|
|
\centering
|
|
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
|
|
\tikzstyle{every pin edge}=[<-,shorten <=1pt]
|
|
\tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
|
|
\tikzstyle{component}=[fmmde, fill=green!50];
|
|
\tikzstyle{failure}=[fmmde, fill=red!50];
|
|
\tikzstyle{symptom}=[fmmde, fill=blue!50];
|
|
\tikzstyle{annot} = [text width=4em, text centered]
|
|
\node[component] (R) at (0,-0.8) {$R$};
|
|
\node[failure] (RSHORT) at (\layersep,-0) {$R_{SHORT}$};
|
|
\node[failure] (ROPEN) at (\layersep,-1.6) {$R_{OPEN}$};
|
|
\path (R) edge (RSHORT);
|
|
\path (R) edge (ROPEN);
|
|
\end{tikzpicture}
|
|
\caption{DAG representing a resistor and its failure modes.}
|
|
\label{fig:rdag}
|
|
\end{figure}
|
|
|
|
Thus $R1$ has failure modes $\{R1_{OPEN}, R1_{SHORT}\}$ and $R2$ has failure modes $\{R2_{OPEN}, R2_{SHORT}\}$.
|
|
%
|
|
We look at each of these base component failure modes,
|
|
and determine how they affect the operation of the potential~divider.
|
|
%Each failure mode scenario we look at will be given a test case number,
|
|
%which is represented on the diagram, with an asterisk marking
|
|
%which failure modes is modelling (see figure \ref{fig:fg1a}).
|
|
%
|
|
Each resistor failure mode is a potential {\fc} in the potential~divider.
|
|
%%For this example we look at single failure modes only.
|
|
For each failure mode in our {\fg}---potential~divider---we can assign a {\fc}
|
|
number (see table \ref{tbl:pdfmea}).
|
|
%
|
|
Each {\fc} is analysed to determine %the symptom of
|
|
a failure in
|
|
the potential~dividers' operation.
|
|
%
|
|
For instance
|
|
if resistor $R_1$ were to become open, then the potential~divider would not be grounded and the
|
|
voltage output from it would float high (+ve).
|
|
%
|
|
This would mean the resulting failure of the potential~divider would be voltage high output.
|
|
%
|
|
The failure mode of a high potential~divider output is termed `HighPD', and
|
|
for it outputting a low voltage `LowPD'. % Andrew asked for this to be defined before the table. ...
|
|
%We can now consider the {\fg}
|
|
%as a component in its own right, and its symptoms as its failure modes.
|
|
%
|
|
{ \small
|
|
\begin{table}[ht]
|
|
\caption{Potential Divider: FMEA for single failures} % title of Table
|
|
\centering % used for centering table
|
|
\begin{tabular}{||l|c|c|l||}
|
|
\hline \hline
|
|
% FIDDLINGING HATAR HAVING TO REMOVE THE TERM FAILURE SCENARIO HERE....
|
|
% GOOD ENOUGH FOR THE IET/IEEE, but then they live in the real
|
|
% world don't they....
|
|
%\textbf{Failure} & \textbf{Pot.Div} & \textbf{Symptom} \\
|
|
%\textbf{scenario} & \textbf{Effect} & \textbf{Description} \\
|
|
|
|
\textbf{Failure } & \textbf{Pot.Div} & \textbf{Derived Component} \\ % \textbf{Symptom} \\
|
|
\textbf{Cause} & \textbf{Effect} & \textbf{Failure modes} \\ %\textbf{Description} \\
|
|
% R & wire & res + & res - & description
|
|
\hline
|
|
\hline
|
|
FC1: $R_1$ SHORT & LOW & LowPD \\
|
|
FC2: $R_1$ OPEN & HIGH & HighPD \\ \hline
|
|
FC3: $R_2$ SHORT & HIGH & HighPD \\
|
|
FC4: $R_2$ OPEN & LOW & LowPD \\ \hline
|
|
\hline
|
|
\end{tabular}
|
|
\label{tbl:pdfmea}
|
|
\end{table}
|
|
}
|
|
%
|
|
%\vbox{
|
|
From table \ref{tbl:pdfmea} we can see that the resistor
|
|
failures modes lead to some common symptoms of failure from the perspective of the {\fg}.
|
|
%YOU FIDDLINGING FITTAS, TELL ME TO USE THE TERM SYMPTOM AND THEN TELL ME TO FIDDLINGING REMOVE IT A YEAR LATER> FITTAS
|
|
%symptoms.
|
|
%These common symptoms of failure are an important concept for FMMD.
|
|
Notice the many to one mapping from {\bc} failure modes to {\dc} failure mode;
|
|
this is a typical effect of an FMMD analysis stage, and means that with each analysis stage we reduce
|
|
the number of failure modes to consider.
|
|
%
|
|
%\fmmdglossDC
|
|
%This means that we can take multiple failure modes from {\fgs} components and resolve them
|
|
%to failure modes of the {\fg}.
|
|
%
|
|
%This means that
|
|
We thus simplify the FMMD analysis task for further stages.
|
|
%
|
|
By drawing vertices for failure modes, % symptoms,
|
|
and edges for the relationships between them
|
|
%component failure modes and
|
|
%{\dc} failure modes. % resultant symptoms.
|
|
%The {\fg} can now be considered a derived component.
|
|
we represent the analysis with the DAG in figure \ref{fig:fg1adag}.
|
|
%}
|
|
%
|
|
\begin{figure}[h]
|
|
\centering
|
|
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
|
|
\tikzstyle{every pin edge}=[<-,shorten <=1pt]
|
|
\tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
|
|
\tikzstyle{component}=[fmmde, fill=green!50];
|
|
\tikzstyle{failure}=[fmmde, fill=red!50];
|
|
\tikzstyle{symptom}=[fmmde, fill=blue!50];
|
|
\tikzstyle{annot} = [text width=4em, text centered]
|
|
|
|
\node[component] (R1) at (0,-1.0) {$R_1$};
|
|
\node[component] (R2) at (0,-3.0) {$R_2$};
|
|
|
|
\node[failure] (R1SHORT) at (\layersep,-0) {$R1_{SHORT}$};
|
|
\node[failure] (R1OPEN) at (\layersep,-1.8) {$R1_{OPEN}$};
|
|
|
|
\node[failure] (R2SHORT) at (\layersep,-3.4) {$R2_{SHORT}$};
|
|
\node[failure] (R2OPEN) at (\layersep,-5.2) {$R2_{OPEN}$};
|
|
|
|
\path (R1) edge (R1SHORT);
|
|
\path (R1) edge (R1OPEN);
|
|
|
|
\path (R2) edge (R2SHORT);
|
|
\path (R2) edge (R2OPEN);
|
|
|
|
% Potential divider failure modes
|
|
%
|
|
\node[symptom] (PDHIGH) at (\layersep*2,-1.0) {HighPD};
|
|
\node[symptom] (PDLOW) at (\layersep*2,-3.0) {LowPD};
|
|
|
|
\path (R1OPEN) edge (PDHIGH);
|
|
\path (R2SHORT) edge (PDHIGH);
|
|
|
|
\path (R2OPEN) edge (PDLOW);
|
|
\path (R1SHORT) edge (PDLOW);
|
|
|
|
\end{tikzpicture}
|
|
|
|
\caption{Failure mode graph of the Potential~Divider}
|
|
\label{fig:fg1adag}
|
|
\end{figure}
|
|
%
|
|
We now have % can now create % formulate
|
|
a {\dc} to represent this potential divider:
|
|
we name this \textbf{PD}.
|
|
\fmmdglossDC
|
|
This {\dc} will have two failure modes, $HighPD$ and $LowPD$.
|
|
% HTR 05SEP2012 We use the symbol $\derivec$ to represent the process of taking the analysed
|
|
% HTR 05SEP2012 {\fg} and creating from it a {\dc}.
|
|
% HTR 05SEP2012 The creation of the {\dc} \textbf{PD} is represented as a
|
|
% HTR 05SEP2012 hierarchy diagram in figure~\ref{fig:dc1}.
|
|
% HTR 05SEP2012 We represent the {\dc} \textbf{PD}, as a DAG in figure \ref{fig:dc1dag}.
|
|
%We could represent it algebraically thus: $ \derivec(PotDiv) =
|
|
% FIDDLINGING OVERSATTNING THIS IS to be REMOVED TOO : FITTAS
|
|
% \begin{figure}[h+]
|
|
% \centering
|
|
% \includegraphics[width=200pt,keepaspectratio=true]{./CH4_FMMD/dc1.png}
|
|
% % dc1.jpg: 430x619 pixel, 72dpi, 15.17x21.84 cm, bb=0 0 430 619
|
|
% \caption{From functional group to derived component, a hierarchical diagram showing how the {\fg} is analysed using the $\derivec$
|
|
% manual process and from this the {\dc} is created.}
|
|
% \label{fig:dc1}
|
|
% \end{figure}
|
|
% We can now represent the potential divider as a {\dc}.
|
|
% Because we have its symptoms (or failure mode behaviour),
|
|
% we can treat these as the failure modes of a new {\dc}.
|
|
% We can represent this as a DAG (see figure \ref{fig:dc1dag}).
|
|
% \begin{figure}[h+]
|
|
% \centering
|
|
% \begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
|
|
% \tikzstyle{every pin edge}=[<-,shorten <=1pt]
|
|
% \tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
|
|
% \tikzstyle{component}=[fmmde, fill=green!50];
|
|
% \tikzstyle{failure}=[fmmde, fill=red!50];
|
|
% \tikzstyle{symptom}=[fmmde, fill=blue!50];
|
|
% \tikzstyle{annot} = [text width=4em, text centered]
|
|
% \node[component] (PD) at (0,-0.8) {{\em PD}};
|
|
% \node[symptom] (PDHIGH) at (\layersep,-0) {$PD_{HIGH}$};
|
|
% \node[symptom] (PDLOW) at (\layersep,-1.6) {$PD_{LOW}$};
|
|
% \path (PD) edge (PDHIGH);
|
|
% \path (PD) edge (PDLOW);
|
|
% \end{tikzpicture}
|
|
% \caption{DAG representing the {\dc} Potential Divider (PD) and its failure modes.}
|
|
% \label{fig:dc1dag}
|
|
% \end{figure}
|
|
%
|
|
% The derived component is defined by its failure modes and
|
|
% the functional group used to derive it.
|
|
% %We can consider this an an orthogonal WHAT???? Group ???? Collection ????
|
|
We now have a {\dc} model for a generic potential divider, and can use it
|
|
as a building block for other {\fgs} in the same way as we used the base components $R1$ and $R2$.
|
|
%
|
|
%\clearpage
|
|
%
|
|
\paragraph{Failure Mode Analysis of a generic op-amp.}
|
|
%
|
|
\label{sec:opamp_fms}
|
|
%\clearpage
|
|
Let us now consider the op-amp as a {\bc}. According to
|
|
FMD-91~\cite{fmd91}[3-116] an op amp may have the following failure modes %(with assigned probabilities):
|
|
latch-up (l\_up), where the output voltage is stuck at high , % (12.5\%),
|
|
latch-down (l\_dn), where the output voltage is stuck low, %(6\%),
|
|
no-operation (noop), where the op-amp cannot drive the output, %(31.3\%),
|
|
and low~slew~rate (lowslew) where the op-amp cannot react quickly to changes on its inputs. %(50\%).
|
|
\nocite{mil1991}
|
|
%
|
|
%\ifthenelse {\boolean{dag}}
|
|
%{
|
|
\fmodegloss
|
|
%
|
|
%\clearpage
|
|
We can represent these failure modes on a DAG (see figure~\ref{fig:op1dag}).
|
|
\begin{figure}[h+]
|
|
\centering
|
|
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
|
|
\tikzstyle{every pin edge}=[<-,shorten <=1pt]
|
|
\tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
|
|
\tikzstyle{component}=[fmmde, fill=green!50];
|
|
\tikzstyle{failure}=[fmmde, fill=red!50];
|
|
\tikzstyle{symptom}=[fmmde, fill=blue!50];
|
|
\tikzstyle{annot} = [text width=4em, text centered]
|
|
|
|
\node[component] (OPAMP) at (0,-1.8) {$OPAMP$};
|
|
|
|
\node[failure] (OPAMPLU) at (\layersep,-0) {l-up};
|
|
\node[failure] (OPAMPLD) at (\layersep,-1.2) {l-dn};
|
|
\node[failure] (OPAMPNP) at (\layersep,-2.4) {noop};
|
|
\node[failure] (OPAMPLS) at (\layersep,-3.6) {lowslew};
|
|
|
|
\path (OPAMP) edge (OPAMPLU);
|
|
\path (OPAMP) edge (OPAMPLD);
|
|
\path (OPAMP) edge (OPAMPNP);
|
|
\path (OPAMP) edge (OPAMPLS);
|
|
|
|
\end{tikzpicture}
|
|
% End of code
|
|
\caption{DAG representing failure modes of an Op-amp}
|
|
\label{fig:op1dag}
|
|
\end{figure}
|
|
%
|
|
%}
|
|
%{
|
|
%}
|
|
%\clearpage
|
|
%\paragraph{Modelling the OP amp with the potential divider.}
|
|
The op-amp and the {\dc} {\em PD} now % andrew heavily critised this sentence but it made sense to Chris and I
|
|
form a {\fg} to model the failure mode behaviour of the non-inverting amplifier.
|
|
%
|
|
%We have the failure modes of the {\dc} for the potential divider,
|
|
%so we do not need to go back and consider the individual resistor failure modes that defined its behaviour.
|
|
%
|
|
%We can now create a {\fg} for the non-inverting amplifier
|
|
%by bringing together the failure modes from \textbf{opamp} and \textbf{PD}.
|
|
%
|
|
The two components in this new {\fg}, the op-amp and the {\dc} {\em PD} have failure modes, which we use
|
|
as {\fcs} in table~\ref{tbl:ampfmea1}.
|
|
%Each of these failure modes will be given a {\fc} for analysis,
|
|
%and this is represented in table \ref{tbl:ampfmea1}.
|
|
% FITTAS NOW I CANNOT USE THE TERM FAILURE SCENARIO---was first column of table below
|
|
%
|
|
%\clearpage
|
|
{\footnotesize
|
|
\begin{table}[h+]
|
|
\caption{Non Inverting Amplifier: Failure Mode Effects Analysis: Single Faults} % title of Table
|
|
\centering % used for centering table
|
|
\begin{tabular}{||l|c|c|l||}
|
|
\hline \hline
|
|
%% FIDDLINGING HATAR HAVING TO REMOVE THE TERM FAILURE SCENARIO --- whats is this the fucking
|
|
%%childrens version
|
|
%\textbf{Failure} & \textbf{Amplifier} & \textbf{Derived component} \\ %Symptom} \\
|
|
% \textbf{Scenario} & \textbf{Effect} & \textbf{Failure Modes} \\ %Description} \\
|
|
%%FFor
|
|
|
|
%%% Undrar jag om fittan ska avstand mot failure fucking cause
|
|
%
|
|
\textbf{Failure} & \textbf{Amplifier} & \textbf{Derived component} \\ %Symptom} \\
|
|
\textbf{Cause} & \textbf{Effect} & \textbf{Failure Mode} \\ %Description} \\
|
|
% R & wire & res + & res - & description
|
|
\hline
|
|
\hline
|
|
FC1: $OPAMP$ & Output & AMPHigh \\
|
|
LatchUP & High & \\ \hline
|
|
|
|
FC2: $OPAMP$ & Output Low& AMPLow \\
|
|
LatchDown & Low gain & \\ \hline
|
|
|
|
FC3: $OPAMP$ & Output Low & AMPLow \\
|
|
No Operation & & \\ \hline
|
|
|
|
FC4: $OPAMP$ & Low pass & LowPass \\
|
|
Low Slew & filtering & \\ \hline
|
|
|
|
FC5: {\em PD} & Output High & AMPHigh \\
|
|
LowPD & & \\ \hline
|
|
|
|
FC6: {\em PD} & Output Low & AMPLow \\
|
|
HighPD & Low Gain & \\ \hline
|
|
%TC7: $R_2$ OPEN & LOW & & LowPD \\ \hline
|
|
\hline
|
|
\end{tabular}
|
|
\label{tbl:ampfmea1}
|
|
\end{table}
|
|
}
|
|
%
|
|
%
|
|
%
|
|
\label{sec:invamp}
|
|
%
|
|
\begin{figure}[h+]
|
|
\centering
|
|
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
|
|
\tikzstyle{every pin edge}=[<-,shorten <=1pt]
|
|
\tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
|
|
\tikzstyle{component}=[fmmde, fill=green!50];
|
|
\tikzstyle{failure}=[fmmde, fill=red!50];
|
|
\tikzstyle{symptom}=[fmmde, fill=blue!50];
|
|
\tikzstyle{annot} = [text width=4em, text centered]
|
|
|
|
% Draw the input layer nodes
|
|
%\foreach \name / \y in {1,...,4}
|
|
% This is the same as writing \foreach \name / \y in {1/1,2/2,3/3,4/4}
|
|
% \node[component, pin=left:Input \#\y] (I-\name) at (0,-\y) {};
|
|
|
|
\node[component] (OPAMP) at (0,-1.8) {$OPAMP$};
|
|
\node[component] (R1) at (0,-7) {$R_1$};
|
|
\node[component] (R2) at (0,-8.6) {$R_2$};
|
|
|
|
%\node[component] (C-3) at (0,-5) {$C^0_3$};
|
|
%\node[component] (K-4) at (0,-8) {$K^0_4$};
|
|
%\node[component] (C-5) at (0,-10) {$C^0_5$};
|
|
%\node[component] (C-6) at (0,-12) {$C^0_6$};
|
|
%\node[component] (K-7) at (0,-15) {$K^0_7$};
|
|
|
|
% Draw the hidden layer nodes
|
|
%\foreach \name / \y in {1,...,5}
|
|
% \path[yshift=0.5cm]
|
|
|
|
\node[failure] (OPAMPLU) at (\layersep,-0) {l-up};
|
|
\node[failure] (OPAMPLD) at (\layersep,-1.2) {l-dn};
|
|
\node[failure] (OPAMPNP) at (\layersep,-2.5) {noop};
|
|
\node[failure] (OPAMPLS) at (\layersep,-3.8) {lowslew};
|
|
|
|
\node[failure] (R1SHORT) at (\layersep,-5.6) {$R1_{SHORT}$};
|
|
\node[failure] (R1OPEN) at (\layersep,-7.4) {$R1_{OPEN}$};
|
|
|
|
\node[failure] (R2SHORT) at (\layersep,-9.0) {$R2_{SHORT}$};
|
|
\node[failure] (R2OPEN) at (\layersep,-11.0) {$R2_{OPEN}$};
|
|
|
|
|
|
|
|
% Draw the output layer node
|
|
|
|
% % Connect every node in the input layer with every node in the
|
|
% % hidden layer.
|
|
% %\foreach \source in {1,...,4}
|
|
% % \foreach \dest in {1,...,5}
|
|
\path (OPAMP) edge (OPAMPLU);
|
|
\path (OPAMP) edge (OPAMPLD);
|
|
\path (OPAMP) edge (OPAMPNP);
|
|
\path (OPAMP) edge (OPAMPLS);
|
|
|
|
\path (R1) edge (R1SHORT);
|
|
\path (R1) edge (R1OPEN);
|
|
|
|
\path (R2) edge (R2SHORT);
|
|
\path (R2) edge (R2OPEN);
|
|
|
|
|
|
% Potential divider failure modes
|
|
%
|
|
\node[symptom] (PDHIGH) at (\layersep*2,-7) {HighPD};
|
|
\node[symptom] (PDLOW) at (\layersep*2,-8.6) {LowPD};
|
|
|
|
|
|
|
|
\path (R1OPEN) edge (PDHIGH);
|
|
\path (R2SHORT) edge (PDHIGH);
|
|
|
|
|
|
\path (R2OPEN) edge (PDLOW);
|
|
\path (R1SHORT) edge (PDLOW);
|
|
|
|
|
|
|
|
\node[symptom] (AMPHIGH) at (\layersep*3.4,-3) {$AMP_{HIGH}$};
|
|
\node[symptom] (AMPLOW) at (\layersep*3.4,-5) {$AMP_{LOW}$};
|
|
\node[symptom] (AMPLP) at (\layersep*3.4,-7) {$LOWPASS$};
|
|
|
|
\path (PDLOW) edge (AMPHIGH);
|
|
\path (OPAMPLU) edge (AMPHIGH);
|
|
|
|
\path (PDHIGH) edge (AMPLOW);
|
|
\path (OPAMPNP) edge (AMPLOW);
|
|
\path (OPAMPLD) edge (AMPLOW);
|
|
|
|
\path (OPAMPLS) edge (AMPLP);
|
|
% %\node[symptom,pin={[pin edge={->}]right:Output}, right of=C-1a] (O) {};
|
|
% \node[symptom, right of=C-1a] (s1) {s1};
|
|
% \node[symptom, right of=C-2a] (s2) {s2};
|
|
%
|
|
%
|
|
%
|
|
% \path (C-2b) edge (s1);
|
|
% \path (C-1a) edge (s1);
|
|
%
|
|
% \path (C-2a) edge (s2);
|
|
% \path (C-1b) edge (s2);
|
|
%
|
|
% %\node[component, right of=s1] (DC) {$C^1_1$};
|
|
%
|
|
% %\path (s1) edge (DC);
|
|
% %\path (s2) edge (DC);
|
|
%
|
|
%
|
|
% `
|
|
% % Connect every node in the hidden layer with the output layer
|
|
% %\foreach \source in {1,...,5}
|
|
% % \path (H-\source) edge (O);
|
|
%
|
|
% % Annotate the layers
|
|
% \node[annot,above of=C-1a, node distance=1cm] (hl) {Failure modes};
|
|
% \node[annot,left of=hl] {Base Components};
|
|
% \node[annot,right of=hl](s) {Symptoms};
|
|
%\node[annot,right of=s](dcl) {Derived Component};
|
|
\end{tikzpicture}
|
|
% End of code
|
|
\caption{Full DAG representing failure modes and {\bcs} of the Non Inverting Op-amp Circuit}
|
|
\label{fig:noninvdag1}
|
|
\end{figure}
|
|
%
|
|
%Let us consider, for the sake of the example, that the voltage follower (very low gain of 1.0)
|
|
%amplification characteristics from FS2 and FS6 can be considered as low output from the OPAMP for the application
|
|
%in hand (say milli-volt signal amplification).
|
|
%
|
|
For this amplifier configuration we have three {\dc} failure modes; {\em AMP\_High, AMP\_Low, LowPass}. % see figure~\ref{fig:fgampb}.
|
|
% HTR 05SEP2012
|
|
This model now has two stages of analysis, as represented in figure~\ref{fig:eulerfmmd}.
|
|
%
|
|
From the analysis in table \ref{tbl:ampfmea1} we can create the {\dc} {\em NONINVAMP}, which
|
|
represents the failure mode behaviour of the non-inverting amplifier.
|
|
%
|
|
% HTR 05SEP2012 \begin{figure}[h]
|
|
% HTR 05SEP2012 % HTR 05SEP2012 \centering
|
|
% HTR 05SEP2012 \includegraphics[width=225pt]{./CH4_FMMD/dc2.png}
|
|
% HTR 05SEP2012 % dc2.png: 635x778 pixel, 72dpi, 22.40x27.45 cm, bb=0 0 635 778
|
|
% HTR 05SEP2012 \caption{Hierarchy representing the two stage FMMD analysis
|
|
% HTR 05SEP2012 (i.e. two `$\derivec$' processes taking {\fgs} and creating {\dcs}) for the non-inverting amplifier}
|
|
% HTR 05SEP2012 \label{fig:dc2}
|
|
% HTR 05SEP2012 \end{figure}
|
|
%
|
|
%
|
|
We can represent the analysis stages of INVAMP as an Euler diagram,
|
|
showing the choice of de-composition of the system into {\fgs} (see figure~\ref{fig:eulerfmmd}).
|
|
%where the curves
|
|
%define the components and {\dcs} used to form the INVAMP model, see figure~\ref{fig:eulerfmmd}.
|
|
%
|
|
\begin{figure}[h]+
|
|
\centering
|
|
\includegraphics[width=300pt]{./CH4_FMMD/eulerfmmd.png}
|
|
% eulerfmmd.png: 413x207 pixel, 72dpi, 14.57x7.30 cm, bb=0 0 413 207
|
|
\caption{FMMD analysis of the INVAMP represented as an Euler diagram, showing how
|
|
the components have been grouped into {\fgs} and then used as {\dcs} to build the analysis hierarchy.}
|
|
\label{fig:eulerfmmd}
|
|
\end{figure}
|
|
%
|
|
%\clearpage %%% This figure seems to escape furher down the chapter
|
|
%
|
|
We can now examine the failure mode relationships in the {\dc} {\em INVAMP} by drawing it as a DAG.
|
|
%expand the {\em PD} {\dc} and have a full FMMD failure %mode
|
|
%model
|
|
We can traverse this DAG, tracing the top level % symptoms
|
|
failure modes
|
|
down to the base component failure modes, %leaves of the tree (the leaves being {\bc} failure modes),
|
|
and thus determine all possible causes for
|
|
the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier {\dc} {\em INVAMP}.
|
|
%
|
|
Knowing all possible causes for a top level event/failure~mode
|
|
is extremely useful;
|
|
if a particular top~level/system~failure was classified as catastrophic for instance,
|
|
we could use this information
|
|
to strengthen components that could cause that particular top level event/system~failure.
|
|
%
|
|
Figure \ref{fig:noninvdag1} shows a DAG,
|
|
from which we can trace top level failure modes to the base component failure modes
|
|
that can cause them.
|
|
That is, we can trace failure mode effects
|
|
from base component level to the top and vice versa.
|
|
|
|
\fmodegloss
|
|
\fmmdgloss
|
|
\fmmdglossFG
|
|
\fmmdglossDC
|
|
\fmmdglossSYMPTOM
|
|
|
|
\section{Defining terms}
|
|
|
|
\paragraph{A discussion on the terms Parts, Components and Base Components.}
|
|
A component is anything we use to build a %a product or
|
|
system.
|
|
It could be something quite complicated
|
|
like an %integrated
|
|
micro-controller/servo motor, or quite simple like the resistor.
|
|
%
|
|
We %can
|
|
usually identify a
|
|
component by its name, a manufacturer's part number and perhaps
|
|
a vendor's reference number. %In a controlled production evironment
|
|
%
|
|
Geoffrey Hall, writing in Spacecraft Systems Engineering~\cite{scse}[p.619]
|
|
defines a `part' thus
|
|
``{{Part(definition)}---The lowest level of assembly, beyond which further disassembly irrevocably destroys the item''.
|
|
%
|
|
This definition %of a `part'
|
|
is useful, but consider parts, such as quad packaged op-amps:
|
|
in this case we have four op-amps on one chip.
|
|
%
|
|
Using traditional FMEA methods~\cite{sccs}[p.34] we would consider each op-amp in the package
|
|
as a separate building block for a circuit. For FMMD each of these four op-amps
|
|
in the chip would be considered to be a separate {\bc}.
|
|
% CAN WE FIND SUPPORT FOR THIS IN LITERATURE???
|
|
\fmmdglossBC
|
|
%
|
|
We need to go further than the above definition of a part, and define % defining
|
|
an atomic entity. % used as a building block.
|
|
%The term component, in American English, can mean a building block or a part.
|
|
%In British-English a component generally is given to mean the definition for part above.
|
|
We define {\bc} to be the lowest level---an entity with which we begin our analysis---a component
|
|
that we use as a starting bottom-up building block.
|
|
%This is a choice made by the analyst, often guided by the standards to which the analysis is being performed. % to.
|
|
%
|
|
Both op-amps and transistors have published statistical failure rates and yet an op-amp is constructed from transistors.
|
|
%
|
|
However, a circuit designer would usually consider individual transistors and individual op-amps
|
|
as lowest level building blocks.
|
|
%
|
|
In fact any lowest level building block with published failure modes could be considered to be a {\bc},
|
|
but this determination is the choice of the analyst, which may be influenced by the particular
|
|
standard~\cite{en298}~\cite{en61508} %~\cite{en230}
|
|
to which we are approving/analysing a system.
|
|
|
|
%a lowest level of assembly `part' or an atomic entity, which ever is the smaller
|
|
%and component to mean either a part or a sub-assembly.
|
|
%Definitions used in FMMD are lisfuckup mode or not?????ted in table~\ref{tbl:fmmd_defs} and discussed below.
|
|
|
|
%% FIDDLINGING STEREO SUB_SYSTEM EXAMPLE, THE FIDDLINGING CHILDRENS SECTION
|
|
|
|
\subsection{Definition of terms: sound system example.}
|
|
\label{sec:cdplayer}
|
|
%000000elpful here to define the terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'.
|
|
%These are listed in table~\ref{tab:symexdef}.
|
|
|
|
A system, is any coherent piece of equipment that performs a given task. % safety critical product.
|
|
%
|
|
A component can be viewed as a sub-system that is a part of some larger system.
|
|
%
|
|
A modular system common to many homes is the sound separates audio system or stereo hi-fi.
|
|
%
|
|
This is used as an example to describe the concepts {\fg} and {\dc} found in FMMD.
|
|
%
|
|
For instance a stereo amplifier separate/slave is a component.
|
|
%The
|
|
A whole sound system consists perhaps of the following components:
|
|
CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
|
|
|
|
\fmmdglossSYS
|
|
\fmmdglossSS
|
|
%Thinking like this is a top~down analysis approach
|
|
%and is the way in which FTA\cite{nucfta} analyses a System
|
|
%and breaks it down.
|
|
\paragraph{Functional Groupings and Components.} % {\fgs} and components.}
|
|
Components can be composed of components, recursively down to
|
|
the {\bcs}.
|
|
%
|
|
\fmmdglossFG
|
|
\fmmdglossBC
|
|
%
|
|
However each component
|
|
will have a fault/failure behaviour and it should
|
|
always be possible to obtain a set of failure modes
|
|
for each component.
|
|
%In FMMD terms a sub-system is a derived component.
|
|
%
|
|
If we look at the sound system example,
|
|
the CD~player could fail in several distinct ways,
|
|
and this could have been caused by a number of {{the CD players internal}} component failure modes.
|
|
%no matter what has happened to it or has gone wrong inside it.
|
|
%
|
|
Using the reasoning that working from the bottom up forces the consideration of all possible
|
|
component failures (which can be missed in a top~down approach \cite{faa}[Ch.9]),
|
|
we are presented with a problem: which initial collections of base components should we choose?
|
|
%
|
|
For instance in the CD~player example, if we start at the bottom, we are presented with
|
|
a massive list of base~components, resistors, motors, user~switches, laser~diodes, etc.
|
|
%Clearly,
|
|
Working from the bottom~up, we need to pick small
|
|
collections of components that work together in some way.
|
|
These collections are termed `{\fgs}'.
|
|
\fmmdglossFG
|
|
%
|
|
For instance, the circuitry that powers the laser diode
|
|
to illuminate the CD might contain a handful of components, and as such would make a good candidate
|
|
as one of the base level {\fgs}. It is a good candidate because
|
|
it performs a well defined function and it could be considered a design module.
|
|
|
|
\paragraph{Functional grouping to {\dc} process outline.}
|
|
%In choosing the lowest level (base component) sub-systems we would look
|
|
%for the smallest `functional~groups' of components within a system.
|
|
%We %can
|
|
%define a
|
|
{\Fgs} have been defined as a set of components that interact
|
|
to perform a specific function.
|
|
%
|
|
When we have analysed the fault behaviour of a {\fg}, we can treat it as a `black~box'.
|
|
%
|
|
\fmmdglossFG
|
|
\fmmdglossDC
|
|
%
|
|
%
|
|
The {\fgs} fault behaviour will consist of a set of %
|
|
failure modes caused by combinations
|
|
of its component's failure modes.
|
|
%
|
|
A new component can be derived from analysing the {\fg} where
|
|
the symptoms of failure of the {\fg} are the failure modes of this new `{\dc}'.
|
|
%
|
|
An outline of the FMMD process is itemised below:
|
|
\begin{itemize}
|
|
\item Collect components to form a {\fg},
|
|
\item Create failure cause `test~cases' for all failure modes of the components within the {\fg},
|
|
\item Analyse the effect of all the test~cases on the operation of the {\fg},
|
|
\item Determine the common failure modes of the {\fg},
|
|
\item Create and name a derived component for the {\fg},
|
|
\item Assign the common failure modes from the {\fg} as the failure modes of the {\dc}.
|
|
\end{itemize}
|
|
\fmmdglossFG
|
|
\fmmdglossDC
|
|
\fmmdgloss
|
|
\fmmdglossBC
|
|
%
|
|
The FMMD process is described in using formal definitions and algorithms in section~\ref{sec:symptomabs}.
|
|
|
|
%We can now call our functional~group a sub-system or a derived~component.
|
|
%The goal here is to know how it will behave under fault conditions !
|
|
%Imagine buying one such `sub~system' from a very honest vendor.
|
|
%One of those sir, yes but be warned it may fail in these distinct ways, here
|
|
%in the honest data sheet the set of failure modes is listed!
|
|
|
|
|
|
%This type of thinking is starting to become more commonplace in product literature, with the emergence
|
|
%of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}.
|
|
%FIT (Failure in Time - expected number of failures per billion hours of operation) values
|
|
%are published for some micro-controllers. A micro~controller
|
|
%is a complex sub-system in its self and could be considered a `black~box' with a given reliability.
|
|
%\footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD
|
|
%1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
% \begin{table}[h+]
|
|
% \caption{CANbus messages id}
|
|
% \begin{tabular}{|p{1cm}|p{10cm}|}
|
|
% \hline \hline
|
|
% \textbf{Bit Field} & \textbf{Description} \\ \hline \hline
|
|
% 29 & Priority bit, set to zero gives the can message high priority in physical layer arbitration.\\ \hline
|
|
% 27-26 & extended source unit, 2 bits (shift left by 4).\\ \hline
|
|
% 25-24 & extended local unit, 2 bits (shift left by 4).\\ \hline
|
|
% 20 & unit to unit bit. This means message for communication between UNITS on the CANbus, not peripheral devices.\\ \hline
|
|
% 19-16 & source unit address (see bits 27-26).\\ \hline
|
|
% 15-12 & local unit address (see bits 25-24).\\ \hline
|
|
% 11 & broadcast bit (for time signals etc.).\\ \hline
|
|
% 10-5 & can handle (6 bit peripheral identifier, used in conjunction with six bit local address).\\ \hline
|
|
% 4 & peripheral bit, set to 0 indicates a message from a UNIT, to 1 from a peripheral.\\ \hline
|
|
% 3-0 & CAN ID message. For messages between peripherals and units, this identifies the message type. \\
|
|
% \hline \hline
|
|
% \end{tabular}
|
|
% \label{tbl:fmmd_defs}
|
|
% \end{table}
|
|
|
|
%What components all have in common is that they can fail, and fail in a
|
|
% number of well defined ways.
|
|
For common {\bcs}
|
|
there is established literature for the failure modes for the system designer to consider
|
|
(often with accompanying statistical
|
|
failure rates)~\cite{mil1991,en298,fmd91}.
|
|
%
|
|
\fmmdglossBC
|
|
%
|
|
For instance, a simple resistor is generally considered
|
|
to fail in two ways, it can go open circuit or it can short.
|
|
%
|
|
Electrical components have data-sheets associated with them. The data sheets
|
|
supply detailed information on the component as supplied by the manufacturer.
|
|
%
|
|
\fmodegloss
|
|
%
|
|
Because they are written for system designers, and to an extent advertise the product,
|
|
they rarely give %show %clearly detail the
|
|
failure modes of the component.
|
|
%
|
|
For FMEA purposes, ideally failure modes along with
|
|
with environmental factors and MTTF~\cite{sccs}[p.165] statistics would be presented.
|
|
%
|
|
Given the growing usage of FMEA/FMEDA and the emergence of SIL as a safety benchmark in industry, this may change.
|
|
%
|
|
Currently, failure mode information is generally only available for generic component types~\cite{mil1991, fmd91}.
|
|
%
|
|
Thus we can associate a set of failure modes to types of component,
|
|
for example $ResistorFaultModes=\{OPEN, SHORT\}$\footnote{The failure modes of the resistor
|
|
are discussed in section~\ref{sec:resistorfm}.}.
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=200pt]{./CH4_FMMD/component.png}
|
|
% component.png: 436x136 pixel, 72dpi, 15.38x4.80 cm, bb=0 0 436 136
|
|
\caption{UML diagram of a component and its associated failure modes.}
|
|
\label{fig:component}
|
|
\end{figure}
|
|
|
|
% \begin{figure}[h]+
|
|
% \centering
|
|
% \includegraphics[width=300pt,bb=0 0 437 141,keepaspectratio=true]{CH4_FMMD/component.png}
|
|
% % component.png: 437x141 pixel, 72dpi, 15.42x4.97 cm, bb=0 0 437 141
|
|
% \caption{A Component and its Failure Modes}
|
|
% \label{fig:component}
|
|
% \end{figure}
|
|
|
|
The UML class diagram in figure
|
|
\ref{fig:component} shows a component as a data
|
|
structure with its associated failure modes.
|
|
%
|
|
From this diagram we see that each component must have at least one failure mode.
|
|
%
|
|
\label{ch4:mutex}
|
|
To clearly show that the failure modes are mutually exclusive states, or unitary states associated with one component,
|
|
each failure mode is referenced back to only one component.
|
|
%
|
|
\fmmdglossMUTEX
|
|
%
|
|
This constraint is discussed in detail in section~\ref{sec:unitarystate}.
|
|
|
|
%%-%% MTTF STATS CHAPTER MAYBE ??
|
|
%%-%%
|
|
%%-%% This modelling constraint is due to the fact that even generic components with the same
|
|
%%-%% failure mode types, may have different statistical MTTF properties within the same
|
|
%%-%% circuitry\footnote{For example, consider resistors one of high resistance and one low.
|
|
%%-%% The generic failure modes for a resistor will be the same for both.
|
|
%%-%% The lower resistance part will draw more current and therefore have a statistically higher chance of failure.}.
|
|
|
|
|
|
%Controlled products are typically built using a large number of components and these are traditionally
|
|
%kept in a `parts~list'.
|
|
%
|
|
%For a safety critical product this is usually a formal document
|
|
%and is used for ordering systems from third parties, and by quality inspectors
|
|
%to ensure the correct parts are being fitted.
|
|
%The parts list is shown for completeness here, as people involved with Printed Circuit Board (PCB) and electronics production, verification and testing would want to know where it lies in the model.
|
|
%The parts list is not actively used in the FMMD method, but is shown in the UML model for completeness.
|
|
%
|
|
%For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a collection of components.
|
|
%
|
|
% \begin{figure}[h]
|
|
% \centering
|
|
% \includegraphics[width=400pt,bb=0 0 712 68,keepaspectratio=true]{CH4_FMMD/componentpl.png}
|
|
% % componentpl.png: 712x68 pixel, 72dpi, 25.12x2.40 cm, bb=0 0 712 68
|
|
% \caption{Parts List of Components}
|
|
% \label{fig:componentpl}
|
|
% \end{figure}
|
|
%
|
|
% %Components in the parts list % (bought in parts)
|
|
%will be termed `base~components'.
|
|
%Components derived from base~components (i.e. sub-assemblies) will not always require
|
|
%parts~numbers\footnote{It is common practise for sub-assemblies, PCB's, mechanical parts,
|
|
%software modules and some collections of components to have part numbers.
|
|
%This is a production/configuration~control issue, and linked to Bill of Material (BOM)~\cite{opmanage}
|
|
%database structures etc. Parts numbers for derived components are not directly related to the analysis process
|
|
%we are concerned with here.}, and will
|
|
%not require a vendor reference, but must be named locally in the FMMD model.
|
|
|
|
%We can term
|
|
By `modularising a system' we mean recursively breaking it into smaller sections for analysis.
|
|
%
|
|
When modularising a system from the top~down, as in Fault Tree Analysis (FTA)~\cite{nasafta}\cite{nucfta} ,
|
|
it is common to term the modules identified as sub-systems.
|
|
%
|
|
\fmmdglossFTA
|
|
\fmmdglossSS
|
|
\fmmdglossFG
|
|
%
|
|
When modularising failure mode behaviour from the bottom up,
|
|
it is more meaningful to call them `{\dcs}'.
|
|
%
|
|
This is because they have been derived from the bottom-up according to functional
|
|
criteria, rather than with the top down approach, de-composed from
|
|
a system into 'sub-systems'.
|
|
%
|
|
\fmodegloss
|
|
\fmmdglossDC
|
|
%
|
|
|
|
\section{Failure Modes in depth}
|
|
|
|
%To perform FMEA appraisals we begin with {\bcs}~\cite{en298}~\cite{bfmea}~\cite{en61508}.
|
|
%These will have a set of failure modes assigned to them.
|
|
In order to perform FMEA we require a set of failure modes for each {\bc} in the system under investigation.
|
|
%
|
|
These are failure modes from the perspective of the user
|
|
of the component.
|
|
%
|
|
We are not usually concerned with how the component has failed
|
|
internally.
|
|
%
|
|
What we need to know are the symptoms of failure.
|
|
%
|
|
\fmmdglossSYMPTOM
|
|
%
|
|
With these symptoms, we can trace their effects through the system under investigation
|
|
and finally determine top-level failure events. % outcomes.
|
|
%
|
|
Different approval agencies may list different failure mode sets for the same generic components.
|
|
%
|
|
This apparent anomaly is discussed in section~\ref{sec:determine_fms} using two common electronic components
|
|
as examples.
|
|
|
|
|
|
|
|
%%
|
|
%% DETAILED LOOK AT TWO COMPONENTS AND THEIR FAILURE MODES
|
|
%%
|
|
%% FROM TWO LITERATURE SOURCES, FMD-91 and EN298
|
|
%%
|
|
%%% THIS HAS BEEN TAKEN OUT AND PLACED IN THE C_GARRET OPAMPS DOCUMENT
|
|
|
|
|
|
|
|
\section{Fault Mode Analysis, top down or bottom up?}
|
|
|
|
Traditional static fault analysis methods work from the top down.
|
|
They identify faults that can occur in a system, and then work down
|
|
to see how they could be caused.
|
|
%
|
|
Some apply statistical techniques to
|
|
determine the likelihood of component failures
|
|
causing specific system level errors.
|
|
%
|
|
For example the FMEA variant FMECA, uses
|
|
Bayes theorem~\cite{probstat}[p.170]~\cite{nucfta}[p.74] (the relation between a conditional probability and its reverse)
|
|
and is applied to specific failure modes in components and their probability of causing given system level errors.
|
|
\fmmdglossFMECA
|
|
Another top down methodology is to apply cost benefit analysis
|
|
to determine which faults are the highest priority to fix~\cite{bfmea}.
|
|
%
|
|
%\fmmdglossFMEA
|
|
\fmeagloss
|
|
%
|
|
The aim of FMMD analysis is to produce complete\footnote{Completeness dependent upon the completeness/correctness of the {\fms} supplied by the germane standard
|
|
for our {\bcs}.} failure
|
|
models of safety critical systems from the bottom-up,
|
|
starting where possible with known base~component failure~modes.
|
|
%
|
|
%
|
|
%
|
|
An advantage of working from the bottom up is that we can ensure that
|
|
all component failure modes must be considered.
|
|
%
|
|
A top down approach (such as FTA)
|
|
can miss individual failure modes of components~\cite{faa}[Ch.~9],
|
|
especially where there are non-obvious top-level faults.
|
|
%
|
|
\fmmdglossFTA
|
|
%
|
|
|
|
|
|
\subsection{From functional group to newly derived component}
|
|
\label{fg}
|
|
The process for taking a {\fg}, analysing its failure mode behaviour, considering
|
|
all the failure modes of all the components in the group
|
|
and collecting symptoms of failure, is termed `symptom abstraction'.
|
|
\fmmdglossSA
|
|
%
|
|
This is dealt with in detail using an algorithmic description, in appendix \ref{sec:algorithmfmmd}.
|
|
\fmmdglossFG
|
|
\fmmdglossDC
|
|
% % define difference between a \fg and a \dc
|
|
% A {\fg} is a collection of components. A {\dc} is a new `theoretical'
|
|
% component which has a set of failure modes,
|
|
% corresponding to the failure symptoms from the {\fg} from which it was derived.
|
|
% %
|
|
% We now consider a {\dc} as a black box, or component
|
|
% for use in further levels of analysis.
|
|
% %, and in this case it would have a set of failure modes.
|
|
% %Looking at the {\fg} in this way is seeing it as a {\dc}.
|
|
|
|
In terms of our UML model (see figure~\ref{fig:cfg}), the symptom abstraction process takes a {\fg}
|
|
and creates a new {\dc} from it.
|
|
%To do this it first creates
|
|
%a new set of failure modes, representing the fault behaviour
|
|
%of the functional group. This is a human process and to do this the analyst
|
|
%must consider all the failure modes of the components in the functional
|
|
%group.
|
|
The newly created {\dc} requires a set of failure modes of its own.
|
|
As a derived component inherits from component, the UML model shows
|
|
that it inherits the property of a set of failure modes.
|
|
%
|
|
%These failure modes are the failure mode behaviour---or symptoms---of the {\fg} from which it was derived.
|
|
%
|
|
%Because these new failure modes were derived from a {\fg}, we can call
|
|
%these `derived~failure~modes'.
|
|
%It then creates a new derived~component object, and associates it to this new set of derived~failure~modes.
|
|
%We thus have a `new' component, %or system building block, but
|
|
%with a known and traceable
|
|
%fault behaviour.
|
|
A {\fg} must comprise of at least one component, and the UML diagram shows this
|
|
with the one to many relationship.
|
|
%
|
|
Under exceptional circumstances a component may need to be a member of more than
|
|
one {\fg} (this is looked at in section~\ref{sec:sideeffects}).
|
|
%
|
|
The relationship between
|
|
the {\fg} and component is therefore---using UML notation---`$ \star \leftrightarrow 1..\star$'.
|
|
%
|
|
A {\fg} will only be associated with one {\dc} and is given a one to one relationship in the UML diagram.
|
|
%
|
|
Each {\fg} will have one analysis report associated with it.
|
|
%
|
|
The UML representation (in figure \ref{fig:cfg}) shows a `{\fg}' having a one to one relationship with a derived~component.
|
|
%
|
|
%
|
|
%%% FORMAL DEF SLIGHTLY OUT OF PLACE HERE ---- J.HOWSE
|
|
% The symbol $\derivec$ is used to indicate the analysis process that takes a
|
|
% functional group and converts it into a new component.
|
|
% \begin{definition}
|
|
% With $\mathcal{\FG}$ representing the set of all functional groups (over all possible components),
|
|
% and $\mathcal{{\DC}}$ the set of all derived components,
|
|
% we express the analysis process $\derivec$ as $$ \derivec : \mathcal{\FG} \rightarrow \mathcal{{\DC}} .$$
|
|
% \end{definition}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=300pt,,keepaspectratio=true]{./CH4_FMMD/cfg.png}
|
|
% cfg.png: 712x286 pixel, 72dpi, 25.12x10.09 cm, bb=0 0 712 286
|
|
\caption{Basic UML Meta model for FMMD hierarchy}
|
|
\label{fig:cfg}
|
|
\end{figure}
|
|
|
|
|
|
%% Here we need how this meta model translates into the FMMD Hierarchy
|
|
|
|
\subsection{How the UML Meta Model maps to an FMMD Hierarchy}
|
|
\label{sec:fmmd_uml}
|
|
%
|
|
The UML meta model above (see figure~\ref{fig:cfg}) describes a hierarchical structure. %% Might be a UML pattern that is well known ..... 05MAY2012
|
|
This is because, as {\dcs} inherit the properties of
|
|
components, {\dcs} may be used to form {\fgs}.
|
|
%
|
|
Consider the hierarchy from the example in figure~\ref{fig:eulerfmmd}. % ~\ref{fig:dc2}.
|
|
%
|
|
The lowest level in this hierarchy are the {\bcs}, the resistors and the op-amp.
|
|
%
|
|
The resistors are collected into a {\fg}, and the ${PD}$ derived component created from its analysis, is shown enclosing R1 and R2. % above the {\fg}.
|
|
%
|
|
As this derived component inherits the properties of a component, we may use
|
|
it in a {\fg} higher in the hierarchy.
|
|
%
|
|
The {\em PD} derived component is now placed into a {\fg}
|
|
with the op-amp.
|
|
%
|
|
This {\fg} is now analysed and a {\dc} created to represent the failure mode behaviour
|
|
of the {\em INVAMP}\footnote{The results of this analysis are placed into the analysis~report. This will contain
|
|
mapping relationships between the component {\fms} and the {\dc} {\fms} and ideally, descriptions that would
|
|
aid auditors to understand the reasoning behind each analysis test~case.}.
|
|
\fmmdglossSS
|
|
%
|
|
%
|
|
We may now use the {\em INVAMP} {\dc} in even higher level {\fgs}.
|
|
%
|
|
An analysis report is generated for each stage in the FMMD % {\fg} to {\dc}
|
|
process. %\footnote
|
|
%
|
|
The UML model in figure~\ref{fig:cfg} describes a hierarchical structure analogous to that of a file system with directories,
|
|
but instead of directory and file nodes, there are closely linked {\fg} and {\dc} pairs, that perform a similar structural function.
|
|
%
|
|
To demonstrate the hierarchical nature of the UML model for FMMD, the NONINVAMP example is presented as an instance
|
|
diagram below (see figure~\ref{fig:instanceNONINVAMP}).
|
|
%
|
|
By tracing the component failure modes to symptoms
|
|
(which would defined in the analysis reports)
|
|
the failure causation logic can be followed and thus the DAG's derived (see figure~\ref{fig:noninvdag1}).
|
|
%
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=400pt]{./CH4_FMMD/instance_diagram_NONINVAMP.png}
|
|
% instance_diagram_NONINVAMP.png: 1162x657 pixel, 72dpi, 40.99x23.18 cm, bb=0 0 1162 657
|
|
\caption{Instance diagram for the NONINVAMP example.}
|
|
\label{fig:instanceNONINVAMP}
|
|
\end{figure}
|
|
|
|
|
|
%
|
|
\paragraph{Traceability and quality of FMMD analysis.}
|
|
By having an analysis report report for each analysis stage, %i.e. {\fg} to {\dc},
|
|
we add traceability to the reasoning applied to the FMMD process.
|
|
%
|
|
Consider that traditional FMEA has one large reasoning stage, that of component failure mode
|
|
directly to system level failure. The reasoning given is typically a one line comment
|
|
on a spreadsheet entry~\cite{sccs}[p.38]. % (if we are lucky!).
|
|
%
|
|
FMMD typically has several reasoning stages (i.e. from each {\fg} to {\dc}) up to the
|
|
final system level {\dc}.
|
|
%
|
|
Thus, each possible cause for a system failure %{\fm}
|
|
will have a collection of FMMD analysis reports associated with it.
|
|
%
|
|
These collections of analysis reports will provide a cause and effect
|
|
story for each possible scenario that could cause the system level failure.
|
|
%
|
|
Traceability of design processes are considered necessary for
|
|
safety critical product~\cite{en61508} and is an important concept
|
|
in quality systems~\cite{iso9001}.
|
|
%
|
|
Having analysis reports increases the traceability---or documented paper trail---aiding understanding
|
|
and maintainability for failure mode models.
|
|
%
|
|
Also a detailed cause and effect model is useful for creating diagnostic schemas~\cite{dbamafta}.
|
|
|
|
|
|
|
|
\paragraph{Keeping track of the derived components position in the hierarchy}
|
|
\label{sec:alpha}
|
|
The UML meta model in figure \ref{fig:cfg}, shows the relationships
|
|
between the entities used in FMMD.
|
|
%
|
|
% Note that because we can use derived components to build functional groups,
|
|
% this model intrinsically supports % building a
|
|
% hierarchy.
|
|
% %
|
|
% In use we will build a hierarchy of
|
|
% objects, functional~groups formed with derived~components, and after symptom~abstraction creating
|
|
% derived components yet higher up in the structure.
|
|
% %
|
|
To keep track of the level in the hierarchy (i.e. how many stages of component
|
|
derivation %`$\derivec$'
|
|
have led to the current derived component)
|
|
we can add an attribute to the component data type.
|
|
This can be a natural number called the level variable $\abslev \in \mathbb{N}$.
|
|
% J. Howse says zero is a given in comp sci. This can be a natural number called the level variable $\alpha \in \mathbb{N}_0$.
|
|
The $\abslev$ level variable in each component,
|
|
indicates the position in the hierarchy. Base components
|
|
have a `level' of $\abslev=0$.
|
|
% I do not know how to make this simpler
|
|
Derived~components take a level based on the highest level
|
|
component used to build the functional group it was derived from plus 1.
|
|
So a derived component built from base level components
|
|
would have an $\abslev$ value of 1.
|
|
%
|
|
In our example the resistors and op-amp are level zero ({\bcs}, $\abslev=0$), the {\em PD} a level 1 {\dc} ($\abslev=1$) and the {\em INVAMP}
|
|
a level 2 {\dc} ($\abslev=2$).
|
|
%\clearpage
|
|
Because {\fgs} may include components at varying levels
|
|
of $\abslev$, having it quickly available as an attribute
|
|
will be required in practical implementations
|
|
to order the tree, and assist in preventing recursion in the hierarchy (i.e. where
|
|
a {\fg} could erroneously include a component above its-self in the hierarchy).
|
|
%
|
|
The abstraction level concept is formally defined in appendix~\ref{sec:abstractionlevel}.
|
|
|
|
% \section{Set Theory Description}
|
|
%
|
|
% $$ System \stackrel{has}{\longrightarrow} PartsList $$
|
|
%
|
|
% $$ PartsList \stackrel{has}{\longrightarrow} Components $$
|
|
%
|
|
% $$ Component \stackrel{has}{\longrightarrow} FailureModes $$
|
|
%
|
|
% $$ FunctionalGroup \stackrel{has}{\longrightarrow} Components $$
|
|
%
|
|
% Using the symbol $\derivec$ to indicate an analysis process that takes a
|
|
% functional group and converts it into a new component.
|
|
%
|
|
% $$ \derivec ( FG ) \rightarrow DerivedComponent $$
|
|
%
|
|
|
|
|
|
%%-
|
|
%%- Need a complete and more complicated UML diagram here
|
|
%%- the other parts were just fragments to illustrate points
|
|
%%-
|
|
%%-
|
|
% \section{Complete UML Diagram}
|
|
%
|
|
% In this section we examine the entities used in FMMD and their relationships.
|
|
% We have been building parts of the data structure up until now,
|
|
% and can now complete the picture.
|
|
% For the complete UML data model we need to consider the system
|
|
% as a data structure.
|
|
%
|
|
%The `parts~list' is the
|
|
%key reference point and starting point. % in the data structure.
|
|
%Our base components are kept here.
|
|
%
|
|
%From the {\bcs} the initial {\fgs} are formed, and from the first {\fgs},
|
|
%the first {\dcs}.
|
|
%
|
|
% \paragraph{Re-factoring the UML model to remove {\fgs}.}
|
|
% While useful for describing the context of the FMMD analysis process,
|
|
% it is desirable to remove the {\fg} from the UML diagram as this is by-product of the analysis process.
|
|
% Figure~\ref{fig:cfg2} presents a final (and simpler) UML model for FMMD.
|
|
% However, the analysis report, is a core feature of FMMD. Having an analysis
|
|
% report associated with each incremental stage in the analysis is a strength
|
|
% compared to traditional FMEA, where we only have one stage (possibly undocumented)
|
|
% for each {\bc} {\fm} to system level event/failure mode.
|
|
% The {\fg} and the analysis report have one to one relationships. We can therefore re-factor
|
|
% these into an analysis report (which would list the components used to
|
|
% make up and thus define the {\fg}) associated with the {\dc}.
|
|
%
|
|
%
|
|
% %
|
|
% % Two other data types/entities are required
|
|
% % however: we need to model environmental and operational states and
|
|
% % where they fit into the data structure.
|
|
% % %
|
|
%
|
|
%
|
|
%
|
|
% % \paragraph{UML Diagram Additional Objects.}
|
|
% % The additional objects System, Environment and Operational States
|
|
% % are added to UML diagram in figure \ref{fig:cfg} are represented in figure \ref{fig:cfg2}.
|
|
%
|
|
% \label{completeuml}
|
|
%
|
|
% \begin{figure}[h]
|
|
% \centering
|
|
% \includegraphics[width=300pt,keepaspectratio=true]{./CH4_FMMD/master_uml.png}
|
|
% % cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
|
|
% \caption{Complete UML diagram}
|
|
% \label{fig:cfg2}
|
|
% \end{figure}
|
|
|
|
|
|
|
|
%% XXX bit of a loose end here, maybe delete this
|
|
|
|
% \subsection{Ontological work on FMEA}
|
|
%
|
|
% Ontological work on FMEA reviewed so far, has concentrated on
|
|
% formalising the natural language process of FMEA and thus
|
|
% defining relationships between components, failure modes and top level outcomes
|
|
% an overview of this work may found here~\cite{ontfmea}.
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\section{Conclusion}
|
|
|
|
%Tie into wish list at end of chapter 3. Solves state explosion, completeness, traceability, models for related such as FMECA
|
|
|
|
\paragraph{Failure model Completeness.}
|
|
It is undesirable to miss any component {\fm} in the analysis process; were this to
|
|
happen our failure model would be incomplete.
|
|
%
|
|
Given the starting conditions of base component {\fms} from the literature,
|
|
we can ensure that all these {\fms} are traceable to subsequent {\dc} {\fms}
|
|
in the model.
|
|
%
|
|
With the above condition true, we term this a `complete' FMMD failure model.
|
|
Ensuring this condition is described in section~\ref{sec:completetest}.
|
|
|
|
\paragraph{Mutual exclusivity of {\dc} failure modes.}
|
|
%
|
|
It is a desirable feature of a component that its failure modes
|
|
are mutually exclusive.
|
|
%
|
|
This also applies to {\dcs} produced in the FMMD process.
|
|
%
|
|
In the FMMD process symptoms are are collected, i.e no component failure modes may be shared
|
|
by a symptom within a {\fg}, and therefore the failure modes of a {\dc} are mutually exclusive.
|
|
%
|
|
Thus FMMD naturally produces {\dcs} with failure modes that are mutually exclusive.
|
|
%
|
|
This property forces the FMMD analyst to
|
|
create failure modes models that have a many to one mapping from {\bc} {\fm}
|
|
to system level failure, or symptom (see section~\ref{sec:onetoone}).
|
|
%
|
|
\fmmdglossMUTEX
|
|
%
|
|
This property, termed a `unitary~state~failure~mode', is examined formally in section~\ref{ch7:mutex}.
|
|
|
|
\paragraph{Objective and contextual/subjective failure symptoms.}
|
|
Because the top level failure symptoms of an FMMD analysis are objective, or the result of reasoning,
|
|
we can have a final stage where we consider the subjective or contextual effects of these symptoms.
|
|
%
|
|
With traditional FMEA methodologies we
|
|
have to make this decision (the contextual effects) for each component {\fm} in the system.
|
|
|
|
|
|
|
|
|
|
|
|
\paragraph{State explosion problem of FMEA solved by FMMD.}
|
|
%
|
|
Because FMMD considers failure modes within functional groups;
|
|
the traditional state explosion problem in FMEA where the ideal of exhaustive FMEA (XFMEA)---where each failure
|
|
mode could be considered in the context of all other components in the system---disappears.
|
|
%
|
|
With FMMD, because the {\fgs} have small numbers of components in them, we can easily apply XFMEA within the {\fgs}.
|
|
%
|
|
In broad terms, FMMD mitigates state explosion by reducing the number of checks---{\fms} against components)---to perform.
|
|
%
|
|
This issue addressed formally in section~\ref{sec:cc}.
|
|
\fmmdgloss
|
|
\fmmdglossSTATEEX
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\paragraph{Uses of the FMMD failure mode model.}
|
|
%
|
|
Having a failure mode graph/model, where base component failure modes are traceable to top event events,
|
|
provides a forward search derived failure mode model.
|
|
%A forward search means that we can apply checks to ensure that
|
|
%all known component failure
|
|
%modes have been considered in the analysis (i.e. completeness as described above).
|
|
%
|
|
This means that for every system level failure we can traverse back to possible failure causes
|
|
in the base components. Coupled with MTTF statistics for the base components
|
|
this allows prediction of statistical failure rates for system level failures (this is
|
|
described in greater detail in section~\ref{sec:determine_fms}).
|
|
%
|
|
We can also use the FMMD model to derive information
|
|
to assist in creating related models such as FTA~\cite{nucfta,nasafta},
|
|
traditional FMEA, FMECA~\cite{safeware}[p.344], FMEDA~\cite{scsh}, diagnostics schemas~\cite{dbamafta}
|
|
and other failure mode analysis methodologies.
|
|
\fmmdglossFTA
|
|
\fmmdglossFMECA
|
|
\fmmdglossFMEDA
|
|
\fmmdgloss
|
|
%\fmmdglossFMEA
|
|
\fmeagloss |