C Garret and J Howse proof readings
This commit is contained in:
Robin Clark
parent
0c9874cf42
commit
473b534ccd
BIN
minutes/CH4_08JUN2012_MEETING.mp3
Normal file
BIN
minutes/CH4_08JUN2012_MEETING.mp3
Normal file
Binary file not shown.
Binary file not shown.
@ -52,11 +52,13 @@
|
||||
|
||||
\section{Introduction}
|
||||
This chapter
|
||||
starts with %an overview of current failure modelling techniques, and then
|
||||
a worked example using the new methodology,
|
||||
considers %starts with %an overview of current failure modelling techniques, and then
|
||||
a worked example to introduce % using
|
||||
the new methodology,
|
||||
Failure Mode Modular De-composition (FMMD).
|
||||
This is followed by a discussion on the design of the FMMD methodology and then
|
||||
an ontological description using UML class models.
|
||||
This is followed by a discussion on the design of the FMMD methodology and then a
|
||||
%an ontological
|
||||
description using UML class models.
|
||||
%A notation is then described to index and classify objects created in FMMD hierarchical models.
|
||||
|
||||
|
||||
@ -459,7 +461,7 @@ commonly used circuit, the non-inverting op amp~\cite{aoe}[p.234], shown in fig
|
||||
\begin{figure}[h+]
|
||||
\centering
|
||||
%\includegraphics[width=100pt,keepaspectratio=true]{../../noninvopamp/noninv.png}
|
||||
\includegraphics[width=100pt,keepaspectratio=true]{./CH4_FMMD/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}
|
||||
@ -468,7 +470,8 @@ commonly used circuit, the non-inverting op amp~\cite{aoe}[p.234], shown in fig
|
||||
|
||||
|
||||
The function of the resistors in this circuit is to set the amplifier gain.
|
||||
They operate as a potential divider and program the minus input on the op-amp
|
||||
They operate as a potential divider\footnote{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.
|
||||
|
||||
@ -476,9 +479,10 @@ defined by $ G_v = 1 + \frac{R2}{R1} $ at the output.
|
||||
\subsection{Potential Divider.}
|
||||
\label{subsec:potdiv}
|
||||
As the resistors work to provide a specific function, that of a potential divider,
|
||||
we can treat them as a functional group. This functional group has two members, $R1$ and $R2$.
|
||||
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$.
|
||||
Using the EN298 specification for resistor failure~\cite{en298}[App.A],
|
||||
we can assign failure modes of $OPEN$ and $SHORT$ to the resistors (assignment of failure modes
|
||||
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)
|
||||
@ -503,29 +507,21 @@ We represent a resistor and its failure modes as a directed acyclic graph (DAG)
|
||||
\end{figure}
|
||||
|
||||
Thus $R1$ has failure modes $\{R1\_OPEN, R1\_SHORT\}$ and $R2$ has failure modes $\{R2\_OPEN, R2\_SHORT\}$.
|
||||
|
||||
|
||||
|
||||
%
|
||||
We look at each of these base component failure modes,
|
||||
and determine how they affect the operation of the potential divider.
|
||||
%Each failure mode scenario we look at will be given a test case number,
|
||||
%which is represented on the diagram, with an asterisk marking
|
||||
%which failure modes is modelling (see figure \ref{fig:fg1a}).
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
%
|
||||
For this example we look at single failure modes only.
|
||||
For each failure mode in our {\fg} `potential~divider',
|
||||
we can assign a {\fc} number (see table \ref{tbl:pdfmea}).
|
||||
Each {\fc} is analysed to determine the `symptom'
|
||||
of the potential dividers' operation. For instance
|
||||
if resistor $R_1$ was to go open, then the circuit would not be grounded and the
|
||||
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 that it
|
||||
gives a high voltage output.%We can now consider the {\fg}
|
||||
This would mean the symptom of the failed potential divider would be voltage high output.%We can now consider the {\fg}
|
||||
%as a component in its own right, and its symptoms as its failure modes.
|
||||
|
||||
{ \small
|
||||
@ -602,12 +598,14 @@ This is represented in the DAG in figure \ref{fig:fg1adag}.
|
||||
\end{figure}
|
||||
|
||||
|
||||
We can now make a `derived component' to represent this potential divider.
|
||||
We can now formulate a `derived component' to represent this potential divider.
|
||||
This can be named \textbf{PD}.
|
||||
This {\dc} will have two failure modes.
|
||||
We can use the symbol $\derivec$ to represent the process of taking the analysed
|
||||
{\fg} and creating from it, a {\dc}. The creation of the {\dc} \textbf{PD} is
|
||||
represented in figure~\ref{fig:dc1}.
|
||||
We then represent the {\dc} as a DAG in figure \ref{fig:dc1dag}.
|
||||
|
||||
|
||||
%We could represent it algebraically thus: $ \derivec(PotDiv) =
|
||||
\begin{figure}[h+]
|
||||
@ -617,7 +615,7 @@ represented in figure~\ref{fig:dc1}.
|
||||
\caption{From functional group to derived component}
|
||||
\label{fig:dc1}
|
||||
\end{figure}
|
||||
We then represent the {\dc} as a DAG in figure \ref{fig:dc1dag}.
|
||||
|
||||
|
||||
% We can now represent the potential divider as a {\dc}.
|
||||
% Because we have its symptoms (or failure mode behaviour),
|
||||
@ -633,7 +631,7 @@ We then represent the {\dc} as a DAG in figure \ref{fig:dc1dag}.
|
||||
\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) {$PD$};
|
||||
\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);
|
||||
@ -655,11 +653,13 @@ We then represent the {\dc} as a DAG in figure \ref{fig:dc1dag}.
|
||||
|
||||
Let use 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):
|
||||
latchup(12.5\%), latchdown(6\%), nooperation(31.3\%), lowslewrate(50\%).
|
||||
latch-up(12.5\%), latch-down(6\%), no-operation(31.3\%), low~slew~rate(50\%).
|
||||
\nocite{mil1991}
|
||||
|
||||
%\ifthenelse {\boolean{dag}}
|
||||
%{
|
||||
|
||||
\clearpage
|
||||
We can represent these failure modes on a DAG (see figure~\ref{fig:op1dag}).
|
||||
\begin{figure}[h+]
|
||||
\centering
|
||||
@ -694,8 +694,8 @@ We can represent these failure modes on a DAG (see figure~\ref{fig:op1dag}).
|
||||
%}
|
||||
%\clearpage
|
||||
%\paragraph{Modelling the OP amp with the potential divider.}
|
||||
We now merge the OP amp and the {\dc} $PD$, to
|
||||
form a {\fg} to represent the non inverting amplifier.
|
||||
We now merge the OP amp and the {\dc} {\em PD}, to
|
||||
form a {\fg} to represent 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.
|
||||
@ -730,10 +730,10 @@ and this is represented in table \ref{tbl:ampfmea1}.
|
||||
FS4: $OPAMP$ & Low pass & LowPass \\
|
||||
Low Slew & filtering & \\ \hline
|
||||
|
||||
FS5: $PD$ & Output High & AMPHigh \\
|
||||
FS5: {\em PD} & Output High & AMPHigh \\
|
||||
LowPD & & \\ \hline
|
||||
|
||||
FS6: $PD$ & Output Low & AMPLow \\
|
||||
FS6: {\em PD} & Output Low & AMPLow \\
|
||||
HighPD & Low Gain & \\ \hline
|
||||
%TC7: $R_2$ OPEN & LOW & & LowPD \\ \hline
|
||||
\hline
|
||||
@ -871,9 +871,9 @@ and this is represented in table \ref{tbl:ampfmea1}.
|
||||
%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 failure modes; $AMPHigh, AMPLow, LowPass$.%see figure~\ref{fig:fgampb}.
|
||||
For this amplifier configuration we have three failure modes; {\em AMP\_High, AMP\_Low, LowPass}.%see figure~\ref{fig:fgampb}.
|
||||
This model now has two stages of analysis hierarchy, as represented in figure~\ref{fig:dc2}.
|
||||
From the analysis in table \ref{tbl:ampfmea1} we can create the {\dc} $INVAMP$, which
|
||||
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.
|
||||
|
||||
\begin{figure}[h]
|
||||
@ -884,11 +884,11 @@ represents the failure mode behaviour of the non-inverting amplifier.
|
||||
\label{fig:dc2}
|
||||
\end{figure}
|
||||
|
||||
We can now examine the {\dc} $INVAMP$ by drawing it as a DAG.
|
||||
%expand the $PD$ {\dc} and have a full FMMD failure %mode
|
||||
We can now examine the {\dc} {\em INVAMP} by drawing it as a DAG.
|
||||
%expand the {\em PD} {\dc} and have a full FMMD failure %mode
|
||||
%model
|
||||
We can traverse this DAG, and thus determine all possible causes for
|
||||
the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier $INVAMP$.
|
||||
the three high level symptoms, i.e. the failure~modes of the non-inverting amplifier {\em INVAMP}.
|
||||
%
|
||||
Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information
|
||||
to assist in building models for FTA, FMEA, FMECA and FMEDA failure mode analysis methodologies.
|
||||
@ -952,7 +952,7 @@ Base Component & An atomic building block used at the lowest level of an FMMD mo
|
||||
{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||
|
||||
|
||||
Component & A building block, this may be a {\bc} or a sub-assembly. \\
|
||||
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
|
||||
|
||||
|
||||
@ -992,16 +992,18 @@ Failure Scenario & A single failure mode (or a combination), used to
|
||||
\end{table}
|
||||
|
||||
|
||||
\subsection{Parts, components and base components}
|
||||
A component is anything we use to build a product or system.
|
||||
It could be something quite complicated
|
||||
like an integrated micro controller, or quite simple like the resistor.
|
||||
\subsection{Parts, Components and Base Components.}
|
||||
A component is anything we use to build %a product or
|
||||
system.
|
||||
It could be something %quite complicated
|
||||
like an %integrated
|
||||
micro-controller, or quite simple like the resistor.
|
||||
%
|
||||
We can define a
|
||||
component by its name, a manufacturers' part number and perhaps
|
||||
component by its name, a manufacturer's part number and perhaps
|
||||
a vendor's reference number.
|
||||
|
||||
Geoffrey Hall, writing in Spacecraft Systems Engineering\cite{scse}[p.619]
|
||||
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''.
|
||||
|
||||
@ -1018,14 +1020,15 @@ and say that we want to define an atomic entity. % used as a building block.
|
||||
We define {\bc} to be the lowest level of component that we use as a building block.
|
||||
This is a choice made by the analyst.
|
||||
%
|
||||
Both op-amps and transistors have published statistical failure rates and yet an op-amp is made out of transistors.
|
||||
Both op-amps and transistors have published statistical failure rates and yet an op-amp is constructed from transistors.
|
||||
%
|
||||
However, a circuit designer would usually consider individual transistors and individual op-amps
|
||||
as lowest level building blocks.
|
||||
%
|
||||
In fact any component with published failure modes could be considered to be a {\bc},
|
||||
but this determination is the choice of the analyst, which may be influenced by the particular
|
||||
standard~\cite{en298}~\cite{en61508}~\cite{en230} to which we are approving/analysing a system.
|
||||
standard~\cite{en298}~\cite{en61508} %~\cite{en230}
|
||||
to which we are approving/analysing a system.
|
||||
|
||||
%a lowest level of assembly `part' or an atomic entity, which ever is the smaller
|
||||
%and component to mean either a part or a sub-assembly.
|
||||
@ -1042,7 +1045,7 @@ A system, is any coherent entity that would be sold as a product. % safety criti
|
||||
%
|
||||
A component is a system that is a part of some larger system.
|
||||
%
|
||||
A modular system common in most homes is the sound separates audio system or stereo hi-fi.
|
||||
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.
|
||||
%
|
||||
@ -1074,7 +1077,7 @@ component failures (which can be missed in a top~down approach \cite{faa}[Ch.9])
|
||||
we are presented with a problem. Which initial collections of base components should we choose?
|
||||
%
|
||||
For instance in the CD~player example; if we start at the bottom, we are presented with
|
||||
a massive list of base~components, resistors, motors, user~switches, laser~diodes, all sorts!
|
||||
a massive list of base~components, resistors, motors, user~switches, laser~diodes, etc.
|
||||
Clearly, working from the bottom~up, we need to pick small
|
||||
collections of components that work together in some way.
|
||||
These collections are termed `{\fgs}'.
|
||||
@ -1113,11 +1116,12 @@ 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 detailed data-sheets associated with them. The data sheets
|
||||
Electrical components have data-sheets associated with them. The data sheets
|
||||
supply detailed information on the component as supplied by the manufacturer.
|
||||
They rarely clearly detail the
|
||||
%
|
||||
Because they are design related they rarely rarely show %clearly detail the
|
||||
failure modes of the component, with environmental factors and MTTF~\cite{sccs}[p.165] statistics.
|
||||
Given the growing useage of FMEA/FMEDA in industry this may change.
|
||||
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}.
|
||||
|
||||
|
||||
@ -1167,7 +1171,7 @@ are discussed in section~\ref{sec:resistorfm}.}.
|
||||
The UML class diagram in figure
|
||||
\ref{fig:component} shows a component as a data
|
||||
structure with its associated failure modes.
|
||||
|
||||
%
|
||||
From this diagram we see that each component must have at least one failure mode.
|
||||
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. This constraint is discussed in section~\ref{sec:unitarystate}.
|
||||
@ -1233,7 +1237,7 @@ internally.
|
||||
%
|
||||
What we need to know are the symptoms of failure.
|
||||
With these symptoms, we can trace their effects through the system under investigation
|
||||
and determine outcomes.
|
||||
and finally determine top-level failure events. % outcomes.
|
||||
%
|
||||
Different approval agencies may list different failure mode sets for the same generic components.
|
||||
%
|
||||
@ -1323,7 +1327,7 @@ Once we have the failure mode behaviour of the {\fg}, we can determine its sympt
|
||||
We could term these symptoms the 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 sort of super component
|
||||
We can now consider the {\fg} as a {\dc} % sort of super component
|
||||
with its own set of failure modes.
|
||||
|
||||
|
||||
@ -1337,15 +1341,15 @@ This
|
||||
is dealt with in detail using an algorithmic description, in appendix \ref{sec:algorithmfmmd}.
|
||||
|
||||
|
||||
% define difference between a \fg and a \dc
|
||||
A {\fg} is a collection of components. A {\dc} is a new `theoretical'
|
||||
component which has a set of failure modes,
|
||||
corresponding to the failure symptoms from the {\fg} from which it was derived.
|
||||
%
|
||||
We now consider a {\dc} as a black box, or component
|
||||
for use in further levels of analysis.
|
||||
%, and in this case it would have a set of failure modes.
|
||||
%Looking at the {\fg} in this way is seeing it as a {\dc}.
|
||||
% % define difference between a \fg and a \dc
|
||||
% A {\fg} is a collection of components. A {\dc} is a new `theoretical'
|
||||
% component which has a set of failure modes,
|
||||
% corresponding to the failure symptoms from the {\fg} from which it was derived.
|
||||
% %
|
||||
% We now consider a {\dc} as a black box, or component
|
||||
% for use in further levels of analysis.
|
||||
% %, and in this case it would have a set of failure modes.
|
||||
% %Looking at the {\fg} in this way is seeing it as a {\dc}.
|
||||
|
||||
In terms of our UML model, the symptom abstraction process takes a {\fg}
|
||||
and creates a new {\dc} from it.
|
||||
@ -1360,7 +1364,8 @@ These failure modes are the failure mode behaviour---or symptoms---of the {\fg}
|
||||
Because these new failure modes were derived from a {\fg}, we can call
|
||||
these `derived~failure~modes'.
|
||||
%It then creates a new derived~component object, and associates it to this new set of derived~failure~modes.
|
||||
We thus have a `new' component, or system building block, but with a known and traceable
|
||||
We thus have a `new' component, %or system building block, but
|
||||
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.
|
||||
@ -1374,7 +1379,7 @@ this can be expressed as $$ \derivec : \mathcal{\FG} \rightarrow \mathcal{{\DC
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=400pt,bb=0 0 712 286,keepaspectratio=true]{./CH4_FMMD/cfg.png}
|
||||
\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}
|
||||
@ -1397,13 +1402,15 @@ The resistors are collected into a {\fg}, and the ${PD}$ derived component creat
|
||||
As this derived component inherits the properties of a component, we may use
|
||||
it in {\fg} higher in the hierarchy.
|
||||
%
|
||||
The $PD$ derived component is now placed into a {\fg}
|
||||
The {\em PD} derived component is now placed into a {\fg}
|
||||
with the op-amp.
|
||||
%
|
||||
This {\fg} is now analysed and a {\dc} created to
|
||||
represent the failure mode behaviour of the $INVAMP$.
|
||||
represent the failure mode behaviour of the {\em INVAMP}.
|
||||
An analysis report is generated for each {\fg} to {\dc}
|
||||
process.
|
||||
%
|
||||
We may now use the $INVAMP$ {\dc} in even higher level {\fgs}.
|
||||
We may now use the {\em INVAMP} {\dc} in even higher level {\fgs}.
|
||||
|
||||
|
||||
|
||||
@ -1412,14 +1419,14 @@ We may now use the $INVAMP$ {\dc} in even higher level {\fgs}.
|
||||
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.
|
||||
%
|
||||
% 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.
|
||||
@ -1433,8 +1440,14 @@ 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 prevent recursion in the hierarchy.
|
||||
|
||||
|
||||
% \section{Set Theory Description}
|
||||
@ -1464,84 +1477,40 @@ would have an $\abslev$ value of 1.
|
||||
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
|
||||
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}.
|
||||
%
|
||||
Two other data types/entities are required
|
||||
however: we need to model environmental and operational states and
|
||||
where they fit into the data structure.
|
||||
%
|
||||
A system will be expected to perform in a given environment.
|
||||
%
|
||||
Environment in the context of this study
|
||||
means external influences under which the System could be expected to work. % under.
|
||||
%
|
||||
A typical data sheet for an electrical component will give
|
||||
a working temperature range, for instance.
|
||||
Mechanical components could be specified for stress and loading limits.
|
||||
%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}.
|
||||
|
||||
|
||||
Systems may have distinct operational states. For instance, a safety critical controller
|
||||
may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until
|
||||
authorised human intervention takes place.
|
||||
A safety critical circuit may have a self test mode which could be operated externally.
|
||||
%
|
||||
Operational states and environmental conditions must be factored into the UML model.
|
||||
|
||||
\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
|
||||
levels of electrical interference, high voltage contamination on supply
|
||||
lines, radiation levels etc.
|
||||
Environmental influences will affect specific components in specific ways.\footnote{A good example of a part
|
||||
affected by environmental conditions, in this case temperature, is the opto-isolator~\cite{tlp181}
|
||||
which is typically affected at around {60 \oc}. Most electrical components are more robust to temperature variations.}.
|
||||
Environmental analysis is thus applicable to components.
|
||||
Environmental influences, such as over stress due to voltage
|
||||
can be eliminated by down-rating of components as discussed in section~\ref{sec:determine_fms}.
|
||||
With given environmental constraints, we can therefore eliminate some failure modes from the model.
|
||||
% 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{Operational states.}
|
||||
Within the field of safety critical engineering, we often encounter
|
||||
elements that include test or self-test facilities.
|
||||
%
|
||||
We also encounter degraded performance
|
||||
(such as only performing functions in an emergency) and lockout/emergency conditions.
|
||||
These can be broadly termed operational states. %, and apply to the
|
||||
%functional groups.
|
||||
%
|
||||
We need to determine which UML class is most appropriate to hold a relationship
|
||||
to operational states.
|
||||
%
|
||||
Consider for instance an electrical circuit that has a TEST line.
|
||||
When the TEST line is activated, it supplies a test signal
|
||||
which will validate the circuit. This circuit will have two operational states,
|
||||
NORMAL and TEST mode.
|
||||
%
|
||||
It seems better to apply the operational states to {\fgs}.
|
||||
%
|
||||
Functional groupings by definition implement functionality, or purpose, and therefore are the best objects to model
|
||||
operational states.% with.
|
||||
|
||||
\paragraph{Inhibit Conditions.}
|
||||
A third data class may be required if modelling of inhibit conditions~\cite{nasatfa}[p.40] is desired.
|
||||
Some failure modes may only be active given specific environmental conditions
|
||||
or when other failures are already active.
|
||||
To model this, an `inhibit' class has been added.
|
||||
This is an optional attribute of
|
||||
a failure mode. This inhibit class can be triggered
|
||||
on a combination of environmental or failure modes.
|
||||
|
||||
|
||||
\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}.
|
||||
% \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}
|
||||
|
||||
|
||||
Binary file not shown.
@ -3,7 +3,7 @@
|
||||
#
|
||||
# Place all .dia files here as .png targets
|
||||
#
|
||||
DIA =
|
||||
DIA = master_uml_further_work.png
|
||||
|
||||
|
||||
doc: $(DIA)
|
||||
@ -20,5 +20,5 @@ doc: $(DIA)
|
||||
|
||||
|
||||
|
||||
copy:
|
||||
copy: $(DIA)
|
||||
echo $@
|
||||
86
submission_thesis/CH7_Conclusion/copy.tex
Normal file
86
submission_thesis/CH7_Conclusion/copy.tex
Normal file
@ -0,0 +1,86 @@
|
||||
|
||||
\section{Further Work}
|
||||
|
||||
\subsection{Environment, operational states and inhibit gates: additions to the UML model.}
|
||||
|
||||
FTA~\cite{nasafta,nucfta} models environmental, operational state and inhibit gates, and these can be incorporated into
|
||||
the FMMD model.
|
||||
|
||||
A system will be expected to perform in a given environment.
|
||||
%
|
||||
Environment in the context of this study
|
||||
means external influences under which the System could be expected to work. % under.
|
||||
%
|
||||
A typical data sheet for an electrical component will give
|
||||
a working temperature range, for instance.
|
||||
Mechanical components could be specified for stress and loading limits.
|
||||
|
||||
|
||||
Systems may have distinct operational states. For instance, a safety critical controller
|
||||
may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until
|
||||
authorised human intervention takes place.
|
||||
A safety critical circuit may have a self test mode which could be operated externally.
|
||||
%
|
||||
Operational states and environmental conditions must be factored into the UML model.
|
||||
|
||||
\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
|
||||
levels of electrical interference, high voltage contamination on supply
|
||||
lines, radiation levels etc.
|
||||
Environmental influences will affect specific components in specific ways.\footnote{A good example of a part
|
||||
affected by environmental conditions, in this case temperature, is the opto-isolator~\cite{tlp181}
|
||||
which is typically affected at around {60 \oc}. Most electrical components are more robust to temperature variations.}.
|
||||
Environmental analysis is thus applicable to components.
|
||||
Environmental influences, such as over stress due to voltage
|
||||
can be eliminated by down-rating of components as discussed in section~\ref{sec:determine_fms}.
|
||||
With given environmental constraints, we can therefore eliminate some failure modes from the model.
|
||||
|
||||
|
||||
\paragraph{Operational states.}
|
||||
Within the field of safety critical engineering, we often encounter
|
||||
elements that include test or self-test facilities.
|
||||
%
|
||||
We also encounter degraded performance
|
||||
(such as only performing functions in an emergency) and lockout/emergency conditions.
|
||||
These can be broadly termed operational states. %, and apply to the
|
||||
%functional groups.
|
||||
%
|
||||
We need to determine which UML class is most appropriate to hold a relationship
|
||||
to operational states.
|
||||
%
|
||||
Consider for instance an electrical circuit that has a TEST line.
|
||||
When the TEST line is activated, it supplies a test signal
|
||||
which will validate the circuit. This circuit will have two operational states,
|
||||
NORMAL and TEST mode.
|
||||
%
|
||||
It seems better to apply the operational states to {\fgs}.
|
||||
%
|
||||
Functional groupings by definition implement functionality, or purpose, and therefore are the best objects to model
|
||||
operational states.% with.
|
||||
|
||||
\paragraph{Inhibit Conditions.}
|
||||
A third data class may be required if modelling of inhibit conditions~\cite{nasatfa}[p.40] is desired.
|
||||
Some failure modes may only be active given specific environmental conditions
|
||||
or when other failures are already active.
|
||||
To model this, an `inhibit' class has been added.
|
||||
This is an optional attribute of
|
||||
a failure mode. This inhibit class can be triggered
|
||||
on a combination of environmental or failure modes.
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
|
||||
\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{completeumlfurtherwork}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=400pt,keepaspectratio=true]{./CH7_Conclusion/master_uml_further_work.png}
|
||||
% cfg2.png: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
|
||||
\caption{FMMD UML diagram, incorporating Environmental, Operational State and Inhibit gates}
|
||||
\label{fig:cfg2}
|
||||
\end{figure}
|
||||
BIN
submission_thesis/CH7_Conclusion/master_uml_further_work.dia
Normal file
BIN
submission_thesis/CH7_Conclusion/master_uml_further_work.dia
Normal file
Binary file not shown.
@ -1,26 +0,0 @@
|
||||
\section{Copy dot tex}
|
||||
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
sample text
|
||||
@ -22,6 +22,6 @@ chapters_sub_make:
|
||||
cd CH4_FMMD; make copy
|
||||
cd CH5_Examples; make copy
|
||||
cd CH6_Evaluation; make copy
|
||||
cd CH7_Conculsion; make copy
|
||||
cd CH7_Conclusion; make copy
|
||||
#cd CH8_finsh_appendixes; make copy
|
||||
|
||||
|
||||
@ -40,7 +40,7 @@
|
||||
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
|
||||
\newcommand{\fm}{\emp failure~mode}
|
||||
\newcommand{\fms}{\emp failure~modes}
|
||||
\newcommand{\FG}{\ensuremath{{G}}}
|
||||
\newcommand{\FG}{\ensuremath{{FG}}}
|
||||
\newcommand{\DC}{\ensuremath{{DC}}}
|
||||
\newcommand{\fg}{\emp functional~grouping}
|
||||
\newcommand{\fgs}{\emp functional~groupings}
|
||||
|
||||
@ -69,7 +69,6 @@
|
||||
\rhead{PhD Thesis}
|
||||
%\begin{document}
|
||||
|
||||
%%% CH1_introduction CH2_FMEA CH3_FMEA_criticism CH4_FMMD CH5_Examples CH6_Evaluation CH7_Conculsion
|
||||
%\typeout{>>--------------------->> introduction}
|
||||
\chapter{Introduction}
|
||||
\input{CH1_introduction/copy}
|
||||
@ -90,7 +89,7 @@
|
||||
\input{CH6_Evaluation/copy}
|
||||
|
||||
\chapter{Conclusion}
|
||||
\input{CH7_Conculsion/copy}
|
||||
\input{CH7_Conclusion/copy}
|
||||
|
||||
\appendix
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user