Massive edit of CH4
This commit is contained in:
parent
7b0e42703d
commit
86f86b316e
@ -7,6 +7,13 @@
|
||||
YEAR = "1992"
|
||||
}
|
||||
|
||||
@BOOK{scsh,
|
||||
AUTHOR = "D. Smith",
|
||||
TITLE = "Safety Critical Stystems Handbook, 3rd Ed. ISBN 978-0-08-096781-3",
|
||||
PUBLISHER = "Butterworth HeinemannH",
|
||||
YEAR = "2011"
|
||||
}
|
||||
|
||||
@ARTICLE{embedsfmea,
|
||||
AUTHOR = "Peter L. Goddard",
|
||||
TITLE = "Validating The Safety of Embedded Real-Time Control Systems using FMEA",
|
||||
|
Binary file not shown.
@ -63,22 +63,80 @@ description and re-factoring process 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].
|
||||
%
|
||||
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}.
|
||||
FMEA is a bottom-up, or forward search failure mode technique starting with
|
||||
base component failure modes~\cite{safeware}[p.341].
|
||||
%
|
||||
Or in other words we determine how the {\fg}, as an entity can fail.
|
||||
%\subsection{FMMD Process in outline.}
|
||||
%
|
||||
We can then create a new theoretical component to represent the {\fg}.
|
||||
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}'.
|
||||
%
|
||||
We call this a {\dc}.
|
||||
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.
|
||||
%
|
||||
This {\dc} has a set of failure modes: we can thus treat it as a `higher~level' component.
|
||||
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].
|
||||
%
|
||||
%In practical term each component failure mode is considered as a `failure~scenario' or 'test~case'
|
||||
%for the {\fg}.
|
||||
%
|
||||
Each of these failure modes %, and optionally combinations of them, are
|
||||
%formed into failure~scenarios 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 derived failure modes of the {\fg}.
|
||||
%
|
||||
Or in other words we can determine how the `{\fg}' can fail.
|
||||
We can now consider the {\fg} as a {\dc} % sort of super component
|
||||
with its own set of failure modes.
|
||||
%
|
||||
% 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}.
|
||||
% %
|
||||
%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}.
|
||||
@ -90,13 +148,16 @@ at the top of the hierarchy.
|
||||
The failure modes of the final or top {\dc}
|
||||
are the failure modes of the system under investigation.
|
||||
%
|
||||
Or in other words we take the traditional FMEA process, and modularise it from the bottom-up.
|
||||
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 analyse an entire system. %, with documented reasoning stages.
|
||||
% %This has advantages of concentrating
|
||||
% %effort in where modules interact,
|
||||
In this way we can incrementally apply FMEA to an entire system. %, with documented reasoning stages.
|
||||
%
|
||||
This has advantages of concentrating
|
||||
effort in where modules interact (interfaces), of
|
||||
being able to re-use work and a saving in the complexity of performing
|
||||
FMEA.
|
||||
%A notation is then described to index and classify objects created in FMMD hierarchical models.
|
||||
|
||||
|
||||
@ -427,9 +488,9 @@ In this way we can incrementally analyse an entire system. %, with documented re
|
||||
%%
|
||||
%% GARK BEGIN
|
||||
|
||||
To demonstrate the principles of FMMD, we use it to analyse a
|
||||
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}.
|
||||
two resistors; a circuit schematic for this is shown in figure \ref{fig:noninvamp}.
|
||||
%
|
||||
\begin{figure}[h+]
|
||||
\centering
|
||||
@ -441,6 +502,7 @@ two resistors, a circuit schematic for this is shown in figure \ref{fig:noninvam
|
||||
\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$)
|
||||
@ -449,7 +511,7 @@ defined by $ G_v = 1 + \frac{R2}{R1} $ at the output.
|
||||
|
||||
\paragraph{Analysing the failure modes of the Potential Divider.}
|
||||
\label{subsec:potdiv}
|
||||
As the resistors work to provide a clearly defined function, that of a potential divider,
|
||||
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---which can be termed a `{\fg}'.
|
||||
This {\fg} has two members, $R1$ and $R2$.
|
||||
%
|
||||
@ -457,13 +519,13 @@ 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}.
|
||||
%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+]
|
||||
@ -495,28 +557,31 @@ and determine how they affect the operation of the potential~divider.
|
||||
%
|
||||
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}
|
||||
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 failure in
|
||||
the potential~dividers' operation. For instance
|
||||
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 symptom of the failed potential~divider would be voltage high output.
|
||||
%
|
||||
The failure symptom of a high potential~divider output is termed `HighPD', and
|
||||
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: Failure Mode Effects Analysis: Single Faults} % title of Table
|
||||
\caption{Potential Divider: Failure Mode Effects Analysis: Single Failures} % title of Table
|
||||
\centering % used for centering table
|
||||
\begin{tabular}{||l|c|c|l||}
|
||||
\hline \hline
|
||||
% FUCKING HATE HAVING TO REMOVE THE TERM FAILURE SCENARIO HERE....
|
||||
% 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} \\
|
||||
@ -536,25 +601,31 @@ for it outputting a low voltage `LowPD'. % Andrew asked for this to be defined b
|
||||
\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 FUCKING CUNTS, TELL ME TO USE THE TERM SYMPTOM AND THEN TELL ME TO FUCKING REMOVE IT A YEAR LATER> CUNTS
|
||||
%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.
|
||||
It means that we can take multiple failure modes from {\fgs} components and resolve them
|
||||
to failure modes of the {\fg}.
|
||||
%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.
|
||||
%
|
||||
This means that we simplify the FMEA analysis task for further stages.
|
||||
By drawing directed edges from the failure modes to the {\dc} failure modes, % symptoms,
|
||||
we show the relationships between the component failure modes and
|
||||
{\dc} failure modes. % resultant symptoms.
|
||||
%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 FMEA 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.
|
||||
This is represented in the DAG in figure \ref{fig:fg1adag}.
|
||||
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]
|
||||
@ -593,12 +664,11 @@ This is represented in the DAG in figure \ref{fig:fg1adag}.
|
||||
|
||||
\end{tikzpicture}
|
||||
|
||||
\caption{Failure symptoms of the `Potential Divider'}
|
||||
\caption{Failure mode graph of the Potential~Divider}
|
||||
\label{fig:fg1adag}
|
||||
\end{figure}
|
||||
|
||||
|
||||
We can now create % formulate
|
||||
%
|
||||
We now have % can now create % formulate
|
||||
a {\dc} to represent this potential divider:
|
||||
we name this \textbf{PD}.
|
||||
This {\dc} will have two failure modes, $HighPD$ and $LowPD$.
|
||||
@ -607,10 +677,8 @@ This {\dc} will have two failure modes, $HighPD$ and $LowPD$.
|
||||
% 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) =
|
||||
% FUCKING HELL THIS IS to be REMOVED TOO : CUNTS
|
||||
% FIDDLINGING OVERSATTNING THIS IS to be REMOVED TOO : FITTAS
|
||||
% \begin{figure}[h+]
|
||||
% \centering
|
||||
% \includegraphics[width=200pt,keepaspectratio=true]{./CH4_FMMD/dc1.png}
|
||||
@ -619,13 +687,10 @@ This {\dc} will have two failure modes, $HighPD$ and $LowPD$.
|
||||
% 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]
|
||||
@ -650,11 +715,11 @@ This {\dc} will have two failure modes, $HighPD$ and $LowPD$.
|
||||
% %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}
|
||||
|
||||
%
|
||||
\paragraph{Failure Mode Analysis of a generic op-amp.}
|
||||
%
|
||||
%\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):
|
||||
@ -663,10 +728,10 @@ 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}}
|
||||
%{
|
||||
|
||||
%
|
||||
%\clearpage
|
||||
We can represent these failure modes on a DAG (see figure~\ref{fig:op1dag}).
|
||||
\begin{figure}[h+]
|
||||
@ -696,14 +761,14 @@ We can represent these failure modes on a DAG (see figure~\ref{fig:op1dag}).
|
||||
\caption{DAG representing failure modes of an Op-amp}
|
||||
\label{fig:op1dag}
|
||||
\end{figure}
|
||||
|
||||
%
|
||||
%}
|
||||
%{
|
||||
%}
|
||||
%\clearpage
|
||||
%\paragraph{Modelling the OP amp with the potential divider.}
|
||||
We now bring the op-amp and the {\dc} {\em PD} together to % andrew heavily critised this sentence but it made sense to Chris and I
|
||||
form a {\fg} to represent the failure mode behaviour of the non-inverting amplifier.
|
||||
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.
|
||||
@ -715,8 +780,8 @@ The two components in this new {\fg}, the op-amp and the {\dc} {\em PD} have fa
|
||||
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}.
|
||||
% CUNTS NOW I CANNOT USE THE TERM FAILURE SCENARIO---was first column of table below
|
||||
|
||||
% FITTAS NOW I CANNOT USE THE TERM FAILURE SCENARIO---was first column of table below
|
||||
%
|
||||
%\clearpage
|
||||
{\footnotesize
|
||||
\begin{table}[h+]
|
||||
@ -724,7 +789,7 @@ as {\fcs} in table~\ref{tbl:ampfmea1}.
|
||||
\centering % used for centering table
|
||||
\begin{tabular}{||l|c|c|l||}
|
||||
\hline \hline
|
||||
%% FUCKING HATE HAVING TO REMOVE THE TERM FAILURE SCENARIO --- whats is this the fucking
|
||||
%% 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} \\
|
||||
@ -760,10 +825,10 @@ as {\fcs} in table~\ref{tbl:ampfmea1}.
|
||||
\label{tbl:ampfmea1}
|
||||
\end{table}
|
||||
}
|
||||
|
||||
|
||||
|
||||
|
||||
%
|
||||
%
|
||||
%
|
||||
%
|
||||
\begin{figure}[h+]
|
||||
\centering
|
||||
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
|
||||
@ -882,20 +947,21 @@ as {\fcs} in table~\ref{tbl:ampfmea1}.
|
||||
%\node[annot,right of=s](dcl) {Derived Component};
|
||||
\end{tikzpicture}
|
||||
% End of code
|
||||
\caption{Full DAG representing failure modes and symptoms of the Non Inverting Op-amp Circuit}
|
||||
\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 hierarchy, as represented in figure~\ref{fig:dc2}.
|
||||
|
||||
% HTR 05SEP2012
|
||||
This model now has two stages of analysis, as represented in figure~\ref{fig:dc2}.
|
||||
%
|
||||
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}
|
||||
@ -904,11 +970,13 @@ represents the failure mode behaviour of the non-inverting amplifier.
|
||||
% 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 hierarchy as an Euler diagram, where the curves
|
||||
define the components and {\dcs} used to form the INVAMP model, see figure~\ref{fig:eulerfmmd}.
|
||||
|
||||
%
|
||||
%
|
||||
We can represent the analysis sstages of INVAMP as an Euler diagram,
|
||||
showing the choice of de-composition of the system into {\fgs}.}
|
||||
%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}
|
||||
@ -917,7 +985,7 @@ define the components and {\dcs} used to form the INVAMP model, see figure~\ref{
|
||||
the components have been grouped into {\fgs} and then used as {\dcs} to build the analysis hierarchy.}
|
||||
\label{fig:eulerfmmd}
|
||||
\end{figure}
|
||||
|
||||
%
|
||||
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
|
||||
@ -926,23 +994,25 @@ 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.
|
||||
%
|
||||
Were a particular top level event to be classified as catastrophic for instance,
|
||||
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/failure.
|
||||
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 to say that we can trace failure mode effects
|
||||
That is, we can trace failure mode effects
|
||||
from base component level to the top and vice versa.
|
||||
%
|
||||
Having a base component failure modes traceable to top event events,
|
||||
provides a a failure mode model, from which
|
||||
we can derive information
|
||||
to assist in building models for FTA, FMEA, FMECA, FMEDA
|
||||
Having a failure mode graph/model where base component failure modes are traceable to top event events,
|
||||
provides a forward search failure mode model.
|
||||
%
|
||||
We can use this 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}
|
||||
and other failure mode analysis methodologies.
|
||||
|
||||
|
||||
@ -970,7 +1040,7 @@ and other failure mode analysis methodologies.
|
||||
|
||||
|
||||
|
||||
\clearpage
|
||||
%\clearpage
|
||||
|
||||
% When analysing a safety critical system using
|
||||
% any form of Failure Mode Effects Analysis (FMEA), we need clearly defined failure modes for
|
||||
@ -982,69 +1052,65 @@ and other failure mode analysis methodologies.
|
||||
|
||||
\section{Defining terms}
|
||||
|
||||
Here we define the terms as used in the worked example.
|
||||
|
||||
\begin{table}[h]
|
||||
\center
|
||||
\begin{tabular}{||p{3cm}|p{10cm}||}
|
||||
|
||||
\hline \hline
|
||||
{\em Definition } & {\em Description} \\ \hline
|
||||
|
||||
System & A product designed to
|
||||
work as a coherent entity \\ \hline
|
||||
|
||||
|
||||
|
||||
Base Component & An atomic building block used at the lowest level of an FMMD model.
|
||||
% \footnote{In the case of combinatorial packaged parts (such as a chip containing
|
||||
% four op-amps, each op-amp on the chip is considered as one atomic, or {\em{\bc}}).}. %% where did this footnote GO????
|
||||
% seems like its a bug in TeX 04JUN2012
|
||||
\\
|
||||
{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
|
||||
|
||||
Component & A building block, this may be a {\bc} or a {\dc}. \\%or manufacturers part. \\
|
||||
{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
|
||||
|
||||
|
||||
%Sub-system & A part of a system, sub-systems may contain sub-systems etc. \\ \hline % in FMMD terminology
|
||||
%this would be both a {\em{\dc}} and a {\fg}. \\
|
||||
%{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
|
||||
%%A part failure mode is the way in which a component fails "functionally" on component level. Often a part has only a few failure modes.
|
||||
Failure mode & A failure mode~\cite{sccs}[p.8] is the way in which a component may fail functionally (i.e. the way in which it can fail to perform
|
||||
its intended function). A component will typically have few failure modes. \\ \hline
|
||||
|
||||
Functional Grouping & A collection of
|
||||
components with a functional purpose.
|
||||
\\ \hline
|
||||
|
||||
% Symptom & A failure symptom of a {\fg}, caused by % WHICH MUST BE UNIQUE AND SEPARATE WITHIN THE \fg
|
||||
% a combination of its component failure modes. \\ \hline
|
||||
|
||||
|
||||
Derived Component & A theoretical component, created to represent the failure
|
||||
mode behaviour of a {\fg}. \\
|
||||
|
||||
{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
|
||||
% Here we define the terms as used in the worked example.
|
||||
%
|
||||
% \begin{table}[h]
|
||||
% \center
|
||||
% \begin{tabular}{||p{3cm}|p{10cm}||}
|
||||
%
|
||||
% \hline \hline
|
||||
% {\em Definition } & {\em Description} \\ \hline
|
||||
%
|
||||
% System & A product designed to
|
||||
% work as a coherent entity \\ \hline
|
||||
%
|
||||
%
|
||||
%
|
||||
% Base Component & An atomic building block used at the lowest level of an FMMD model.
|
||||
% % \footnote{In the case of combinatorial packaged parts (such as a chip containing
|
||||
% % four op-amps, each op-amp on the chip is considered as one atomic, or {\em{\bc}}).}. %% where did this footnote GO????
|
||||
% % seems like its a bug in TeX 04JUN2012
|
||||
% \\
|
||||
% {\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
%
|
||||
%
|
||||
% Component & A building block, this may be a {\bc} or a {\dc}. \\%or manufacturers part. \\
|
||||
% {\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
%
|
||||
%
|
||||
%
|
||||
% %Sub-system & A part of a system, sub-systems may contain sub-systems etc. \\ \hline % in FMMD terminology
|
||||
% %this would be both a {\em{\dc}} and a {\fg}. \\
|
||||
% %{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
%
|
||||
% %%A part failure mode is the way in which a component fails "functionally" on component level. Often a part has only a few failure modes.
|
||||
% Failure mode & A failure mode~\cite{sccs}[p.8] is the way in which a component may fail functionally (i.e. the way in which it can fail to perform
|
||||
% its intended function). A component will typically have few failure modes. \\ \hline
|
||||
%
|
||||
% Functional Grouping & A collection of
|
||||
% components with a functional purpose.
|
||||
% \\ \hline
|
||||
%
|
||||
% % Symptom & A failure symptom of a {\fg}, caused by % WHICH MUST BE UNIQUE AND SEPARATE WITHIN THE \fg
|
||||
% % a combination of its component failure modes. \\ \hline
|
||||
%
|
||||
%
|
||||
% Derived Component & A theoretical component, created to represent the failure
|
||||
% mode behaviour of a {\fg}. \\
|
||||
%
|
||||
% {\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
% UNITARY STATE NOT DISCUSSED HERE NOW......
|
||||
% Unitary State & A component with `unitary~state' failure modes, means that it cannot fail
|
||||
% with more than one of its failure modes at a time.\\ \hline
|
||||
|
||||
|
||||
%%%% TOLD TO REMOVE THIS BUT FUCKING HATE TO HAVE TO DO IT
|
||||
%%%% TOLD TO REMOVE THIS BUT FIDDLINGING HATAR TO HAVE TO DO IT
|
||||
% Failure Scenario & A single failure mode (or a combination), used to
|
||||
% determine failure mode effects on a {\fg}.
|
||||
\\
|
||||
|
||||
\hline
|
||||
\end{tabular}
|
||||
\caption{Failure Mode Modular De-composition: definitions and terms}
|
||||
\label{tbl:fmmd_defs}
|
||||
\end{table}
|
||||
%\\
|
||||
% \hline
|
||||
% \end{tabular}
|
||||
% \caption{Failure Mode Modular De-composition: definitions and terms}
|
||||
% \label{tbl:fmmd_defs}
|
||||
% \end{table}
|
||||
|
||||
|
||||
\paragraph{A discussion on the terms Parts, Components and Base Components.}
|
||||
@ -1063,18 +1129,20 @@ 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:
|
||||
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.
|
||||
%
|
||||
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
|
||||
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???
|
||||
%
|
||||
We, in fact, need to go a little further than the above definition of a part,
|
||||
and say that we want to define an atomic entity. % used as a building block.
|
||||
We, need to go further than the above definition of a part 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---of component that we use as a building block.
|
||||
We define {\bc} to be the lowest level---an entity with which we begin our analysis---a component
|
||||
that we use as a 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.
|
||||
@ -1091,7 +1159,7 @@ to which we are approving/analysing a system.
|
||||
%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.
|
||||
|
||||
%% FUCKING STEREO SUB_SYSTEM EXAMPLE, THE FUCKING CHILDRENS SECTION
|
||||
%% FIDDLINGING STEREO SUB_SYSTEM EXAMPLE, THE FIDDLINGING CHILDRENS SECTION
|
||||
|
||||
\subsection{Definition of terms: sound system example.}
|
||||
|
||||
@ -1104,7 +1172,7 @@ 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 now used as an example to describe terms used in FMMD.
|
||||
This is used as an example to describe terms used in FMMD.
|
||||
%
|
||||
For instance a stereo amplifier separate/slave is a component.
|
||||
%The
|
||||
@ -1115,13 +1183,13 @@ CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
|
||||
%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
|
||||
Components can be composed of components, recursively down to
|
||||
the {\bcs}.
|
||||
%
|
||||
However each `component'
|
||||
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'.
|
||||
for each component.
|
||||
%In FMMD terms a sub-system is a derived component.
|
||||
%
|
||||
If we look at the sound system example,
|
||||
@ -1135,7 +1203,8 @@ we are presented with a problem: which initial collections of base components sh
|
||||
%
|
||||
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
|
||||
%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}'.
|
||||
%
|
||||
@ -1147,15 +1216,17 @@ 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 {\fg} as a set of components that interact
|
||||
We %can
|
||||
define a {\fg} 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'.
|
||||
When we have analysed the fault behaviour of a {\fg}, we can treat it as a `black~box'.
|
||||
%
|
||||
The {\fgs} fault behaviour will consist of a set of `symptoms' caused by combinations
|
||||
of its component failure modes.
|
||||
The {\fgs} fault behaviour will consist of a set of %
|
||||
failure modes caused by combinations
|
||||
of its component's failure modes.
|
||||
%
|
||||
We can thus create a new `component' derived from analysing the {\fg} where
|
||||
We can thus create a new component derived from analysing the {\fg} where
|
||||
%
|
||||
the symptoms of failure of the {\fg} are the failure modes of this new `{\dc}'.
|
||||
|
||||
@ -1174,13 +1245,7 @@ the symptoms of failure of the {\fg} are the failure modes of this new `{\dc}'.
|
||||
%\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}
|
||||
|
||||
Electrical components have data-sheets associated with them. The data sheets
|
||||
supply detailed information on the component as supplied by the manufacturer.
|
||||
%
|
||||
Because they are design related they rarely show %clearly detail the
|
||||
failure modes of the component, with environmental factors and MTTF~\cite{sccs}[p.165] statistics.
|
||||
Given the growing usage of FMEA/FMEDA in industry this may change.
|
||||
Currently, failure mode information is generally only available for generic component types~\cite{mil1991, fmd91}.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -1215,6 +1280,13 @@ failure rates)~\cite{mil1991,en298,fmd91}.
|
||||
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.
|
||||
%
|
||||
Because they are design related they rarely show %clearly detail the
|
||||
failure modes of the component, with environmental factors and MTTF~\cite{sccs}[p.165] statistics.
|
||||
Given the growing usage of FMEA/FMEDA 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 faults to this component $ResistorFaultModes=\{OPEN, SHORT\}$\footnote{The failure modes of the resistor
|
||||
are discussed in section~\ref{sec:resistorfm}.}.
|
||||
|
||||
@ -1273,7 +1345,8 @@ each failure mode is referenced back to only one component. This constraint is d
|
||||
%we are concerned with here.}, and will
|
||||
%not require a vendor reference, but must be named locally in the FMMD model.
|
||||
|
||||
We can term `modularising a system', to mean recursively breaking it into smaller sections for analysis.
|
||||
%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.
|
||||
@ -1330,10 +1403,13 @@ and is applied to specific failure modes in components and their probability of
|
||||
Another top down methodology is to apply cost benefit analysis
|
||||
to determine which faults are the highest priority to fix~\cite{bfmea}.
|
||||
%
|
||||
The aim of FMMD analysis is to produce complete failure
|
||||
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.
|
||||
%
|
||||
@ -1341,58 +1417,6 @@ A top down approach
|
||||
can miss individual failure modes of components~\cite{faa}[Ch.~9],
|
||||
especially where there are non-obvious top-level faults.
|
||||
|
||||
\subsection{FMMD Process in outline.}
|
||||
|
||||
In order to analyse from the bottom-up, we need to take
|
||||
small groups of components that naturally
|
||||
work together to perform a simple function.
|
||||
%
|
||||
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].
|
||||
%
|
||||
%In practical term each component failure mode is considered as a `failure~scenario' or 'test~case'
|
||||
%for the {\fg}.
|
||||
%
|
||||
Each of these failure modes %, and optionally combinations of them, are
|
||||
%formed into failure~scenarios 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 derived failure modes of the {\fg}.
|
||||
%
|
||||
Or in other words we can determine how the `{\fg}' can fail.
|
||||
We can now consider the {\fg} as a {\dc} % sort of super component
|
||||
with its own set of failure modes.
|
||||
|
||||
|
||||
\subsection{From functional group to newly derived component}
|
||||
@ -1432,12 +1456,13 @@ with a known and traceable
|
||||
fault behaviour.
|
||||
|
||||
The UML representation (in figure \ref{fig:cfg}) shows a `{\fg}' having a one to one relationship with a derived~component.
|
||||
|
||||
%
|
||||
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, and $\mathcal{{\DC}}$ the set of all derived components,
|
||||
this can be expressed as $$ \derivec : \mathcal{\FG} \rightarrow \mathcal{{\DC}} $$ .
|
||||
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]
|
||||
@ -1473,11 +1498,22 @@ represent the failure mode behaviour of the {\em INVAMP}.
|
||||
%
|
||||
An analysis report is generated as part of the {\fg} to {\dc}
|
||||
process. %\footnote
|
||||
{By having an analysis report report for each analysis stage, i.e. {\fg} to {\dc},
|
||||
we add traceability to the reasoning applied to to the FMEA process.}
|
||||
By having an analysis report report for each analysis stage,
|
||||
%i.e. {\fg} to {\dc},
|
||||
we add traceability to the reasoning applied to the FMEA process.
|
||||
%
|
||||
Traditional FMEA has one large reasoning stage, that of component failure mode
|
||||
directly to system level failure.
|
||||
Consider that traditional FMEA has one large reasoning stage, that of component failure mode
|
||||
directly to system level failure. The reasoning given is typically one line
|
||||
on a spreadsheet entry~\cite{sccs}[p.38]. % (if we are lucky!).
|
||||
%
|
||||
FMMD typically has several reasoning stages from {\dc} {\fms} to system level failure modes.
|
||||
Thus, each possible cause for a system {\fm} will have a collection of 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.
|
||||
%
|
||||
This increases the traceability---or documented paper trail---for the understanding of the
|
||||
failure event causes.
|
||||
%
|
||||
We may now use the {\em INVAMP} {\dc} in even higher level {\fgs}.
|
||||
|
||||
@ -1516,7 +1552,7 @@ a level 2 {\dc} ($\abslev=2$).
|
||||
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 prevent recursion in the hierarchy.
|
||||
to order the tree, and assist in preventing recursion in the hierarchy.
|
||||
The abstraction level concept is formally defined in section~\ref{sec:abstractionlevel}.
|
||||
|
||||
% \section{Set Theory Description}
|
||||
@ -1541,55 +1577,55 @@ The abstraction level concept is formally defined in section~\ref{sec:abstractio
|
||||
%%- 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.
|
||||
|
||||
% \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{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}.
|
||||
%
|
||||
%
|
||||
% %
|
||||
|
||||
|
||||
|
||||
% \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}
|
||||
% % 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}
|
||||
|
||||
|
||||
|
||||
|
@ -645,7 +645,7 @@ as a component with a known set of failure modes.
|
||||
|
||||
|
||||
\paragraph{Enumerating abstraction levels}
|
||||
\ref{sec:abstractionlevel}
|
||||
\label{sec:abstractionlevel}
|
||||
We can assign an attribute of abstraction level $\abslev$ to
|
||||
components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$).
|
||||
For a base component, let the abstraction level be zero.
|
||||
|
@ -18,10 +18,10 @@
|
||||
\usepackage{lastpage}
|
||||
\usetikzlibrary{shapes,snakes}
|
||||
\newcommand{\tickYES}{\checkmark}
|
||||
%% FUCKING CUNTS \newcommand{\fc}{fault~scenario}
|
||||
\newcommand{\fc}{fault~cause}
|
||||
%% FUCKING CUNTS \newcommand{\fcs}{fault~scenarios}
|
||||
\newcommand{\fcs}{fault~causes}
|
||||
%% \newcommand{\fc}{fault~scenario}
|
||||
\newcommand{\fc}{failure~cause}
|
||||
%% \newcommand{\fcs}{fault~scenarios}
|
||||
\newcommand{\fcs}{failure~causes}
|
||||
% Page layout definitions to suit A4 paper
|
||||
\setcounter{secnumdepth}{3} \setcounter{tocdepth}{4}
|
||||
\setlength{\topmargin}{0mm}
|
||||
|
Loading…
Reference in New Issue
Block a user