1267 lines
50 KiB
TeX
1267 lines
50 KiB
TeX
%%
|
|
%% CHAPTER 4 : Failure Mode Modular Discrimination
|
|
%%
|
|
\label{sec:chap4}
|
|
|
|
|
|
\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,
|
|
small groups of components that naturally
|
|
work together to perform simple functions are chosen: these groups are termed `{\fgs}'.
|
|
%
|
|
\fmmdglossFG
|
|
%
|
|
The components to include in a {\fg} are chosen by hand.
|
|
%a human, the analyst.
|
|
%piss 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.
|
|
With a {\fg} the failure modes of all the components that belong to it can be determined.
|
|
%
|
|
%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.
|
|
%
|
|
%piss 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 be considered as a `failure~scenario' or 'test~case'
|
|
to be applied to the {\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 the failure mode behaviour of the {\fg} is obtained, its symptoms of failure can be determined.
|
|
%,
|
|
%or the failure modes of the {\dc}.
|
|
%for the {\fg}.
|
|
%
|
|
These symptoms are then treated as failure modes of the {\fg}.
|
|
%
|
|
\fmmdglossFG
|
|
\fmmdglossSYMPTOM
|
|
%Or in other words
|
|
That is, how the {\fg} can fail has been determined.
|
|
%
|
|
As a set of failure modes has been defined for the {\fg} it can be treated as a component in its own right.
|
|
%
|
|
The {\fg} can be considered as a `{\dc}' % sort of super component
|
|
with its own set of failure modes.
|
|
%
|
|
\fmmdglossDC
|
|
%
|
|
%
|
|
%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}.
|
|
Because a {\dc} has a set of failure modes it can be used in higher level {\fgs}
|
|
which in turn produce higher level {\dcs}.
|
|
%
|
|
These {\dcs} can be used 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, the traditional FMEA process has been taken and modularised from the bottom-up.
|
|
%piss 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 FMEA is applied incrementally to an entire system. %, with documented reasoning stages.
|
|
\fmmdglossDC
|
|
\fmmdgloss
|
|
%
|
|
This has advantages of concentrating
|
|
effort 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}
|
|
%
|
|
%
|
|
The principles of FMMD are demonstrated, by using it to analyse a
|
|
common circuit, the 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.
|
|
%
|
|
\fmmdglossOPAMP
|
|
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.
|
|
\fmmdglossOPAMP
|
|
|
|
\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,
|
|
they can be treated 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}).
|
|
%
|
|
A resistor and its failure modes are represented as a directed acyclic graph (DAG)
|
|
in 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}\}$.
|
|
%
|
|
Each of these base component failure modes are examined
|
|
to 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 this {\fg}---potential~divider---a {\fc}
|
|
number is assigned (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 go 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. ...
|
|
%piss 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} it can be seen that the resistor
|
|
failure 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
|
|
the number of failure modes to consider has been reduced.
|
|
%
|
|
%\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
|
|
The FMMD analysis task is therefore simplified 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.
|
|
analysis is represented by 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}
|
|
%
|
|
%piss now have % can now create % formulate
|
|
A {\dc} to represent this potential divider has been created :
|
|
this is named \textbf{PD}.
|
|
%
|
|
\fmmdglossDC
|
|
This {\dc} will have two failure modes, $HighPD$ and $LowPD$.
|
|
% HTR 05SEP2012 piss 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 piss represent the {\dc} \textbf{PD}, as a DAG in figure \ref{fig:dc1dag}.
|
|
%piss 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}
|
|
% piss 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}.
|
|
% piss 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.
|
|
% %piss can consider this an an orthogonal WHAT???? Group ???? Collection ????
|
|
This {\dc} model for a generic potential divider can be used
|
|
as a building block for other {\fgs} in the same way that the base components $R1$ and $R2$ were.
|
|
%
|
|
%\clearpage
|
|
%
|
|
\paragraph{Failure Mode Analysis of a generic op-amp.}
|
|
%
|
|
\label{sec:opamp_fms}
|
|
%\clearpage
|
|
Consider the op-amp as a {\bc}.
|
|
\fmmdglossOPAMP
|
|
%
|
|
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
|
|
These op-amp failure modes are represented on the DAG in 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} are now % andrew heavily critised this sentence but it made sense to Chris and I
|
|
formed into a {\fg} to model the failure mode behaviour of the non-inverting amplifier.
|
|
\fmmdglossOPAMP
|
|
%
|
|
%piss 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.
|
|
%
|
|
%piss 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 are used
|
|
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
|
|
%%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 there are 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} the {\dc} {\em NONINVAMP} can be created, 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}
|
|
%
|
|
%
|
|
The analysis stages of INVAMP are presented as an Euler diagram,
|
|
showing the choice of de-composition of the system into {\fgs} in 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 collected 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
|
|
%
|
|
The failure mode relationships in the {\dc} {\em INVAMP} can be traced through the DAG.
|
|
%expand the {\em PD} {\dc} and have a full FMMD failure %mode
|
|
%model
|
|
It is possible to 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 {\bc} 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,
|
|
this information could be used
|
|
to strengthen components that could cause that particular top level event/system~failure.
|
|
%
|
|
%
|
|
Figure \ref{fig:noninvdag1} shows a DAG,
|
|
where top level failure modes can be traced to the base component failure modes
|
|
that can cause them.
|
|
%
|
|
That is, failure mode effects can be traced
|
|
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 used to build a %a product or
|
|
system.
|
|
It could be something quite complicated
|
|
like an %integrated
|
|
micro-controller/servo motor, or quite simple like a resistor.
|
|
%
|
|
A
|
|
component is usually identified 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.
|
|
\fmmdglossOPAMP
|
|
%
|
|
Using traditional FMEA methods~\cite{sccs}[p.34] each op-amp in the package would be considered
|
|
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
|
|
%
|
|
The above definition of a part, needs further refinement, i.e. to be defined as % 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.
|
|
{\Bc} is defined as the lowest level entity ---an entity with which we begin our analysis---a component
|
|
used 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.
|
|
\fmmdglossOPAMP
|
|
%
|
|
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 the system is being approved/analysed.
|
|
|
|
%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 of {\fg} and {\dc} used by 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 on 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.
|
|
%
|
|
Looking 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]),
|
|
a problem is encountered: which initial collections of base components should we choose?
|
|
%
|
|
For instance in the CD~player example, if we start at the bottom,
|
|
a massive list of base~components will be found, resistors, motors, user~switches, laser~diodes, etc.
|
|
%Clearly,
|
|
Working from the bottom~up, it is necessary 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.
|
|
%piss %can
|
|
%define a
|
|
{\Fgs} have been defined as a set of components that interact
|
|
to perform a specific function.
|
|
%
|
|
After analysis of the fault behaviour of a {\fg}, it can be treated 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 `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 using formal definitions and algorithms in section~\ref{sec:symptomabs}.
|
|
}
|
|
|
|
%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.
|
|
%
|
|
Data sheets, supplied by the manufacturer,
|
|
are a detailed source of information on the component.
|
|
%
|
|
\fmodegloss
|
|
%
|
|
Because they are written for system designers, and to an extent advertise the product,
|
|
they rarely list %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 it can be seen 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}.
|
|
%
|
|
%
|
|
%
|
|
By `modularising a system' this means 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}' (i.e. 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 a set of failure modes is required for each {\bc} in the system under investigation.
|
|
%
|
|
These are failure modes from the perspective of the user
|
|
of the component.
|
|
%
|
|
The FMEA analyst is not usually concerned with how the component has failed
|
|
internally.
|
|
%
|
|
What the analyst needs to know are the symptoms of failure.
|
|
%
|
|
\fmmdglossSYMPTOM
|
|
%
|
|
With these symptoms, their effects can be traced through the system under investigation
|
|
and finally top-level failure events can be determined. % 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, such as FTA~\cite{nucfta,nasafta} 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 it can be ensured that
|
|
all component failure modes have been considered.
|
|
%
|
|
A top down approach (such as FTA)
|
|
can miss~\cite{faa}[Ch.~9] individual failure modes of components,
|
|
especially where there are non-obvious or unexpected top-level failures.
|
|
%
|
|
\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 examined 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.
|
|
% %
|
|
% piss 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 the 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.
|
|
%piss 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 is shown 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.
|
|
\fmmdglossOPAMP
|
|
%
|
|
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, it may be used
|
|
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 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
|
|
%
|
|
%
|
|
The {\em INVAMP} {\dc} may now be used 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 lead to 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,cbds}.
|
|
|
|
|
|
|
|
\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}_{0}$.
|
|
% 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{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,
|
|
it can be ensured that all these {\fms} are traceable to subsequent {\dc} {\fms}
|
|
in the model.
|
|
%
|
|
With the above condition true, this is termed 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 naturally mutually exclusive.
|
|
%
|
|
This also applies to {\dcs} produced in the FMMD process.
|
|
%
|
|
In the FMMD process common symptoms are are collected, i.e no component failure modes may be %shared
|
|
linked to more than one symptom 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 this decision (the contextual effects)
|
|
has to be made 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--which lead to the ideal of XFMEA---disappears.
|
|
%
|
|
With FMMD, because the {\fgs} have small numbers of components in them, XFMEA can be easily applied 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 level/system 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}).
|
|
%
|
|
%%The connections from a given system~failure can be used to determine the
|
|
%%components that are necessary to function correctly to avoid its occurrence.
|
|
%
|
|
%
|
|
% NO dependency trees are logical contructs, I dont think FMMD helps here
|
|
% Thus dependency trees~\cite{cbds}[Ch.5] can be derived from
|
|
% FMMD models by collecting system failure modes in terms of their
|
|
% system level application (i.e. if system level failures $\alpha,beta$ or $\gamma$ occur function $\omega$
|
|
% of the system will be impaired, and )
|
|
% %
|
|
The FMMD model can also be used 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{cbds,dbamafta}
|
|
and other failure mode analysis methodologies.
|
|
%
|
|
\fmmdglossFTA
|
|
\fmmdglossFMECA
|
|
\fmmdglossFMEDA
|
|
\fmmdgloss
|
|
%\fmmdglossFMEA
|
|
\fmeagloss
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|