removed all refs to parts~list
lease enter the commit message for your changes. Lines starting
This commit is contained in:
parent
610ee04008
commit
91f27bb94b
Binary file not shown.
Binary file not shown.
Binary file not shown.
@ -56,7 +56,7 @@ starts with %an overview of current failure modelling techniques, and then
|
|||||||
a worked example using the new methodology,
|
a worked example using the new methodology,
|
||||||
Failure Mode Modular De-composition (FMMD).
|
Failure Mode Modular De-composition (FMMD).
|
||||||
This is followed by a discussion on the design of the FMMD methodology and then
|
This is followed by a discussion on the design of the FMMD methodology and then
|
||||||
an ontological description is given using UML class models.
|
an ontological description using UML class models.
|
||||||
%A notation is then described to index and classify objects created in FMMD hierarchical models.
|
%A notation is then described to index and classify objects created in FMMD hierarchical models.
|
||||||
|
|
||||||
|
|
||||||
@ -648,7 +648,7 @@ We then represent the {\dc} as a DAG in figure \ref{fig:dc1dag}.
|
|||||||
% We now have a {\dc} model for a generic potential divider, and can use it
|
% 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$.
|
% as a building block for other {\fgs} in the same way as we used the base components $R1$ and $R2$.
|
||||||
|
|
||||||
\clearpage
|
%\clearpage
|
||||||
|
|
||||||
%\paragraph{Failure Mode Analysis of the OP-AMP}
|
%\paragraph{Failure Mode Analysis of the OP-AMP}
|
||||||
|
|
||||||
@ -691,7 +691,7 @@ We can represent these failure modes on a DAG (see figure~\ref{fig:op1dag}).
|
|||||||
%}
|
%}
|
||||||
%{
|
%{
|
||||||
%}
|
%}
|
||||||
\clearpage
|
%\clearpage
|
||||||
%\paragraph{Modelling the OP amp with the potential divider.}
|
%\paragraph{Modelling the OP amp with the potential divider.}
|
||||||
We now merge the OP amp and the {\dc} $PD$, to
|
We now merge the OP amp and the {\dc} $PD$, to
|
||||||
form a {\fg} to represent the non inverting amplifier.
|
form a {\fg} to represent the non inverting amplifier.
|
||||||
@ -872,7 +872,7 @@ and this is represented in table \ref{tbl:ampfmea1}.
|
|||||||
|
|
||||||
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; $AMPHigh, AMPLow, LowPass$.%see figure~\ref{fig:fgampb}.
|
||||||
This model now has two stages of analysis hierarchy, as represented in figure~\ref{fig:dc2}.
|
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} $INVAMP$, which
|
||||||
represents the failure mode behaviour of the non-inverting amplifier.
|
represents the failure mode behaviour of the non-inverting amplifier.
|
||||||
|
|
||||||
\begin{figure}[h]
|
\begin{figure}[h]
|
||||||
@ -886,7 +886,7 @@ represents the failure mode behaviour of the non-inverting amplifier.
|
|||||||
We can now examine the {\dc} $INVAMP$ by drawing it as a DAG.
|
We can now examine the {\dc} $INVAMP$ by drawing it as a DAG.
|
||||||
%expand the $PD$ {\dc} and have a full FMMD failure %mode
|
%expand the $PD$ {\dc} and have a full FMMD failure %mode
|
||||||
%model
|
%model
|
||||||
We can traverse this DAG, and thus determine all possible causes to
|
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 $INVAMP$.
|
||||||
%
|
%
|
||||||
Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information
|
Figure \ref{fig:noninvdag1} shows a fully expanded DAG, from which we can derive information
|
||||||
@ -943,14 +943,14 @@ System & A product designed to
|
|||||||
|
|
||||||
|
|
||||||
|
|
||||||
Base Component & An atomic building block used at the lowest level of the FMMD model
|
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
|
\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}}).}.
|
four op-amps, each op-amp on the chip is considered as one atomic, or {\em{\bc}}).}.
|
||||||
\\
|
\\
|
||||||
{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||||
|
|
||||||
|
|
||||||
Component & A building block, this may be a part from a parts list or a sub-assembly. \\
|
Component & A building block, this may be a {\bc} or a sub-assembly. \\
|
||||||
{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
{\em Constraint} & This object must have a defined set of failure~modes. \\ \hline
|
||||||
|
|
||||||
|
|
||||||
@ -1009,7 +1009,7 @@ Here we have four op-amps on one chip. For FMEA we would consider each op-amp in
|
|||||||
as a separate building block for a circuit.
|
as a separate building block for a circuit.
|
||||||
%
|
%
|
||||||
We, in fact, need to go a little further than the above definition of a part,
|
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.
|
and say that we want to define an atomic entity. % used as a building block.
|
||||||
%The term component, in American English, can mean a building block or a part.
|
%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.
|
%In British-English a component generally is given to mean the definition for part above.
|
||||||
We define {\bc} to be the lowest level of component that we use as a building block.
|
We define {\bc} to be the lowest level of component that we use as a building block.
|
||||||
@ -1017,11 +1017,12 @@ 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 made out of transistors.
|
||||||
%
|
%
|
||||||
A circuit designer would consider individual transistors and individual op-amps
|
However, a circuit designer would usually consider individual transistors and individual op-amps
|
||||||
as lowest level building blocks.
|
as lowest level building blocks.
|
||||||
|
%
|
||||||
In fact any component with published failure modes could be considered to be a {\bc},
|
In fact any component with published failure modes could be considered to be a {\bc},
|
||||||
but this determination is the choice of the analyst or the guidelines of the
|
but this determination is the choice of the analyst or the guidelines of the
|
||||||
standard~\cite{en298}~\cite{en61508}~\cite{en230} to which we are approving the product to.
|
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
|
%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.
|
%and component to mean either a part or a sub-assembly.
|
||||||
@ -1051,7 +1052,7 @@ CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
|
|||||||
%and is the way in which FTA\cite{nucfta} analyses a System
|
%and is the way in which FTA\cite{nucfta} analyses a System
|
||||||
%and breaks it down.
|
%and breaks it down.
|
||||||
\paragraph{ {\fgs} and components.}
|
\paragraph{ {\fgs} and components.}
|
||||||
A components will be composed of `components', recursively down to
|
Components can be composed of `components', recursively down to
|
||||||
the {\bcs}.
|
the {\bcs}.
|
||||||
%
|
%
|
||||||
However each `component'
|
However each `component'
|
||||||
@ -1059,17 +1060,16 @@ will have a fault/failure behaviour and it should
|
|||||||
always be possible to obtain a set of failure modes
|
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.
|
%In FMMD terms a sub-system is a derived component.
|
||||||
|
%
|
||||||
If we look at the sound system example,
|
If we look at the sound system example,
|
||||||
the CD~player could fail in several distinct ways,
|
the CD~player could fail in several distinct ways,
|
||||||
and this could have been caused by a number of {\textbf{the CD players internal}} component failure modes.
|
and this could have been caused by a number of {\textbf{the CD players internal}} component failure modes.
|
||||||
%no matter what has happened to it or has gone wrong inside it.
|
%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
|
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])
|
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?
|
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
|
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, all sorts!
|
||||||
Clearly, working from the bottom~up, we need to pick small
|
Clearly, working from the bottom~up, we need to pick small
|
||||||
@ -1085,10 +1085,10 @@ as one of the base level {\fgs}.
|
|||||||
%for the smallest `functional~groups' of components within a system.
|
%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.
|
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 fault behaviour will consist of a set of `symptoms' caused by combinations
|
The {\fgs} fault behaviour will consist of a set of `symptoms' caused by combinations
|
||||||
of its component failure modes.
|
of its component failure modes.
|
||||||
%
|
%
|
||||||
We can thus make a new `component' derived from the symptoms found as a result of analysing the {\fg}.
|
We can thus make a new `component' derived from the symptoms found as a result of analysing the {\fg}.
|
||||||
@ -1175,24 +1175,26 @@ each failure mode is referenced back to only one component. This constraint is d
|
|||||||
%%-%% The lower resistance part will draw more current and therefore have a statistically higher chance of failure.}.
|
%%-%% The lower resistance part will draw more current and therefore have a statistically higher chance of failure.}.
|
||||||
|
|
||||||
|
|
||||||
Controlled products are typically built using a large number of components and these are traditionally
|
%Controlled products are typically built using a large number of components and these are traditionally
|
||||||
kept in a `parts~list'.
|
%kept in a `parts~list'.
|
||||||
%
|
%
|
||||||
For a safety critical product this is usually a formal document
|
For a safety critical product this is usually a formal document
|
||||||
and is used for ordering systems from third parties, and by quality inspectors
|
and is used for ordering systems from third parties, and by quality inspectors
|
||||||
to ensure the correct parts are being fitted.
|
to ensure the correct parts are being fitted.
|
||||||
%The parts list is shown for completeness here, as people involved with Printed Circuit Board (PCB) and electronics production, verification and testing would want to know where it lies in the model.
|
%The parts list is shown for completeness here, as people involved with Printed Circuit Board (PCB) and electronics production, verification and testing would want to know where it lies in the model.
|
||||||
The parts list is not actively used in the FMMD method, but is shown in the UML model for completeness.
|
%The parts list is not actively used in the FMMD method, but is shown in the UML model for completeness.
|
||||||
For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a collection of components.
|
%
|
||||||
\begin{figure}[h]
|
%For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a collection of components.
|
||||||
\centering
|
%
|
||||||
\includegraphics[width=400pt,bb=0 0 712 68,keepaspectratio=true]{CH4_FMMD/componentpl.png}
|
% \begin{figure}[h]
|
||||||
% componentpl.png: 712x68 pixel, 72dpi, 25.12x2.40 cm, bb=0 0 712 68
|
% \centering
|
||||||
\caption{Parts List of Components}
|
% \includegraphics[width=400pt,bb=0 0 712 68,keepaspectratio=true]{CH4_FMMD/componentpl.png}
|
||||||
\label{fig:componentpl}
|
% % componentpl.png: 712x68 pixel, 72dpi, 25.12x2.40 cm, bb=0 0 712 68
|
||||||
\end{figure}
|
% \caption{Parts List of Components}
|
||||||
|
% \label{fig:componentpl}
|
||||||
%Components in the parts list % (bought in parts)
|
% \end{figure}
|
||||||
|
%
|
||||||
|
% %Components in the parts list % (bought in parts)
|
||||||
%will be termed `base~components'.
|
%will be termed `base~components'.
|
||||||
%Components derived from base~components (i.e. sub-assemblies) will not always require
|
%Components derived from base~components (i.e. sub-assemblies) will not always require
|
||||||
%parts~numbers\footnote{It is common practise for sub-assemblies, PCB's, mechanical parts,
|
%parts~numbers\footnote{It is common practise for sub-assemblies, PCB's, mechanical parts,
|
||||||
@ -1203,15 +1205,17 @@ For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a c
|
|||||||
%not require a vendor reference, but must be named locally in the FMMD model.
|
%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 `modularising a system', to 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} ,
|
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.
|
it is common to term the modules identified as sub-systems.
|
||||||
|
%
|
||||||
When modularising failure mode behaviour from the bottom up, it is more meaningful to call them `derived~components'.
|
When modularising failure mode behaviour from the bottom up, it is more meaningful to call them `derived~components'.
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\section{Failure Modes in depth}
|
\section{Failure Modes in depth}
|
||||||
|
|
||||||
For FMEA appraisals of systems we begin with {\bcs}.
|
FMEA appraisals of systems we begin with {\bcs}~\cite{en298}~\cite{bfmea}~\cite{en61508}.
|
||||||
%These will have a set of failure modes assigned to them.
|
%These will have a set of failure modes assigned to them.
|
||||||
In order to perform FMEA we require a set of failure modes for each {\bc} in the system under investigation.
|
In order to perform FMEA we require a set of failure modes for each {\bc} in the system under investigation.
|
||||||
%
|
%
|
||||||
@ -1226,6 +1230,7 @@ With these symptoms, we can trace their effects through the system under investi
|
|||||||
and determine outcomes.
|
and determine outcomes.
|
||||||
%
|
%
|
||||||
Different approval agencies may list different failure mode sets for the same generic components.
|
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
|
This apparent anomaly is discussed in section~\ref{sec:determine_fms} using two common electronic components
|
||||||
as examples.
|
as examples.
|
||||||
|
|
||||||
@ -1244,27 +1249,35 @@ as examples.
|
|||||||
|
|
||||||
Traditional static fault analysis methods work from the top down.
|
Traditional static fault analysis methods work from the top down.
|
||||||
They identify faults that can occur in a system, and then work 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
|
to see how they could be caused.
|
||||||
|
%
|
||||||
|
Some apply statistical techniques to
|
||||||
determine the likelihood of component failures
|
determine the likelihood of component failures
|
||||||
causing specific system level errors. For example the FMEA variant FMECA, uses
|
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)
|
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.
|
and is applied to specific failure modes in components and their probability of causing given system level errors.
|
||||||
Another top down methodology is to apply cost benefit analysis
|
Another top down methodology is to apply cost benefit analysis
|
||||||
to determine which faults are the highest priority to fix~\cite{bfmea}.
|
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 failure
|
||||||
models of safety critical systems from the bottom-up,
|
models of safety critical systems from the bottom-up,
|
||||||
starting, where possible with known base~component failure~modes.
|
starting, where possible with known base~component failure~modes.
|
||||||
|
|
||||||
An advantage of working from the bottom up is that we can ensure that
|
An advantage of working from the bottom up is that we can ensure that
|
||||||
all component failure modes must be considered. A top down approach
|
all component failure modes must be considered.
|
||||||
|
%
|
||||||
|
A top down approach
|
||||||
can miss individual failure modes of components~\cite{faa}[Ch.~9],
|
can miss individual failure modes of components~\cite{faa}[Ch.~9],
|
||||||
especially where there are non-obvious top-level faults.
|
especially where there are non-obvious top-level faults.
|
||||||
|
|
||||||
\subsection{FMMD Process in outline.}
|
\subsection{FMMD Process in outline.}
|
||||||
|
|
||||||
In order to analyse from the bottom-up, we need to take
|
In order to analyse from the bottom-up, we need to take
|
||||||
small groups of components from the parts~list that naturally
|
small groups of components that naturally
|
||||||
work together to perform a simple function.
|
work together to perform a simple function.
|
||||||
|
%
|
||||||
The components to include in a {\fg} are chosen by hand.
|
The components to include in a {\fg} are chosen by hand.
|
||||||
%a human, the analyst.
|
%a human, the analyst.
|
||||||
%We can represent the `Functional~Group' as a class.
|
%We can represent the `Functional~Group' as a class.
|
||||||
@ -1272,6 +1285,8 @@ The components to include in a {\fg} are chosen by hand.
|
|||||||
`{\fg}' we can look at the components it contains,
|
`{\fg}' we can look at the components it contains,
|
||||||
and from this determine the failure modes of all the components that belong to it.
|
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.
|
% and determine a failure mode model for that group.
|
||||||
%
|
%
|
||||||
% expand 21sep2010
|
% expand 21sep2010
|
||||||
@ -1280,18 +1295,26 @@ and from this determine the failure modes of all the components that belong to i
|
|||||||
%can fail.
|
%can fail.
|
||||||
%
|
%
|
||||||
All the failure modes of all the components within a {\fg} are collected.
|
All the failure modes of all the components within a {\fg} are collected.
|
||||||
|
%
|
||||||
As each component mode holds a set of failure modes, the {\fg} represents a set of sets of failure modes.
|
As each component mode holds a set of failure modes, the {\fg} represents a set of sets of failure modes.
|
||||||
|
%
|
||||||
We convert this
|
We convert this
|
||||||
into a flat set
|
into a flat set
|
||||||
of failure modes for use in analysis.
|
of failure modes for use in analysis.
|
||||||
|
%
|
||||||
A flat set is a set containing just failure modes and not sets of failure modes~\cite{joyofsets}[p.8].
|
A flat set is a set containing just 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
|
Each of these failure modes, and optionally combinations of them, are
|
||||||
formed into `test cases' which are
|
formed into `test~cases' which are
|
||||||
analysed for their effect on the failure mode behaviour of the `{\fg}'.
|
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 a new set of failure modes, the derived failure modes of the
|
Once we have the failure mode behaviour of the {\fg}, we can determine a the symptoms of failure
|
||||||
`{\fg}'.
|
for the {\fg}.
|
||||||
|
%
|
||||||
|
We could term these symptoms the derived failure modes of the `{\fg}'.
|
||||||
%
|
%
|
||||||
Or in other words we can determine how the `{\fg}' can fail.
|
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 sort of super component
|
||||||
@ -1303,21 +1326,18 @@ with its own set of failure modes.
|
|||||||
The process for taking a {\fg}, analysing its failure mode behaviour considering
|
The process for taking a {\fg}, analysing its failure mode behaviour considering
|
||||||
all the failure modes of all the components in the group,
|
all the failure modes of all the components in the group,
|
||||||
and collecting symptoms of failure, is termed `symptom abstraction'.
|
and collecting symptoms of failure, is termed `symptom abstraction'.
|
||||||
\ifthenelse {\boolean{paper}}
|
%
|
||||||
{
|
|
||||||
}
|
|
||||||
{
|
|
||||||
This
|
This
|
||||||
is dealt with in detail using an algorithmic description, in section \ref{sec:algorithmfmmd}.
|
is dealt with in detail using an algorithmic description, in section \ref{sec:algorithmfmmd}.
|
||||||
}
|
|
||||||
|
|
||||||
% define difference between a \fg and a \dc
|
% define difference between a \fg and a \dc
|
||||||
A {\fg} is a collection of components, a {\dc} is a new `theoretical'
|
A {\fg} is a collection of components, a {\dc} is a new `theoretical'
|
||||||
component which has a set of failure modes,
|
component which has a set of failure modes,
|
||||||
corresponding to the failure symptoms from the {\fg} from which it was derived.
|
corresponding to the failure symptoms from the {\fg} from which it was derived.
|
||||||
%
|
%
|
||||||
We consider a {\dc} as a black box, or component
|
We now consider a {\dc} as a black box, or component
|
||||||
for use.
|
for use in further levels of analysis.
|
||||||
%, and in this case it would have a set of failure modes.
|
%, 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}.
|
%Looking at the {\fg} in this way is seeing it as a {\dc}.
|
||||||
|
|
||||||
@ -1329,7 +1349,7 @@ and creates a new {\dc} from it.
|
|||||||
%must consider all the failure modes of the components in the functional
|
%must consider all the failure modes of the components in the functional
|
||||||
%group.
|
%group.
|
||||||
The newly created {\dc} requires a set of failure modes of its own.
|
The newly created {\dc} requires a set of failure modes of its own.
|
||||||
These failure modes are the failure mode behaviour of the {\fg} from which it was derived.
|
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
|
Because these new failure modes were derived from a {\fg}, we can call
|
||||||
these `derived~failure~modes'.
|
these `derived~failure~modes'.
|
||||||
@ -1337,7 +1357,7 @@ these `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.
|
fault behaviour.
|
||||||
|
|
||||||
The UML representation (in figure \ref{fig:cfg}) shows a `functional group' having a one to one relationship with a derived~component.
|
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
|
The symbol $\derivec$ is used to indicate the analysis process that takes a
|
||||||
functional group and converts it into a new component.
|
functional group and converts it into a new component.
|
||||||
@ -1385,6 +1405,7 @@ We may now use the $INVAMP$ {\dc} in even higher level {\fgs}.
|
|||||||
\label{sec:alpha}
|
\label{sec:alpha}
|
||||||
The UML meta model in figure \ref{fig:cfg}, shows the relationships
|
The UML meta model in figure \ref{fig:cfg}, shows the relationships
|
||||||
between the entities used in FMMD.
|
between the entities used in FMMD.
|
||||||
|
%
|
||||||
Note that because we can use derived components to build functional groups,
|
Note that because we can use derived components to build functional groups,
|
||||||
this model intrinsically supports % building a
|
this model intrinsically supports % building a
|
||||||
hierarchy.
|
hierarchy.
|
||||||
@ -1404,7 +1425,7 @@ have a `level' of $\abslev=0$.
|
|||||||
% I do not know how to make this simpler
|
% I do not know how to make this simpler
|
||||||
Derived~components take a level based on the highest level
|
Derived~components take a level based on the highest level
|
||||||
component used to build the functional group it was derived from plus 1.
|
component used to build the functional group it was derived from plus 1.
|
||||||
So a derived component built from base level or parts list components
|
So a derived component built from base level components
|
||||||
would have an $\abslev$ value of 1.
|
would have an $\abslev$ value of 1.
|
||||||
%\clearpage
|
%\clearpage
|
||||||
|
|
||||||
@ -1440,14 +1461,17 @@ 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.
|
as a data structure.
|
||||||
|
|
||||||
The `parts~list' is the
|
%The `parts~list' is the
|
||||||
key reference point and starting point. % in the data structure.
|
%key reference point and starting point. % in the data structure.
|
||||||
Our base components are kept here.
|
%Our base components are kept here.
|
||||||
From these the initial {\fgs} are formed, and from the first {\fgs},
|
|
||||||
the first {\dcs}. Two other data types/entities are required
|
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
|
however: we need to model environmental and operational states and
|
||||||
where they fit into the data structure.
|
where they fit into the data structure.
|
||||||
|
%
|
||||||
A system will be expected to perform in a given environment.
|
A system will be expected to perform in a given environment.
|
||||||
%
|
%
|
||||||
Environment in the context of this study
|
Environment in the context of this study
|
||||||
@ -1458,11 +1482,11 @@ a working temperature range, for instance.
|
|||||||
Mechanical components could be specified for stress and loading limits.
|
Mechanical components could be specified for stress and loading limits.
|
||||||
|
|
||||||
|
|
||||||
Systems or sub-systems may have distinct operational states. For instance, a safety critical controller
|
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
|
may have a LOCKOUT state where it has detected a serious problem and will not continue to operate until
|
||||||
authorised human intervention takes place.
|
authorised human intervention takes place.
|
||||||
A safety critical circuit may have a self test mode.
|
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.
|
Operational states and environmental conditions must be factored into the UML model.
|
||||||
|
|
||||||
\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
|
\paragraph{Environmental Modelling.} The external influences/environment could typically be temperature ranges,
|
||||||
@ -1470,7 +1494,7 @@ levels of electrical interference, high voltage contamination on supply
|
|||||||
lines, radiation levels etc.
|
lines, radiation levels etc.
|
||||||
Environmental influences will affect specific components in specific ways.\footnote{A good example of a part
|
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}
|
affected by environmental conditions, in this case temperature, is the opto-isolator~\cite{tlp181}
|
||||||
which is typically affected at around \oc{60}. Most electrical components are far more robust to temperature.}.
|
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 analysis is thus applicable to components.
|
||||||
Environmental influences, such as over stress due to voltage
|
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}.
|
can be eliminated by down-rating of components as discussed in section~\ref{sec:determine_fms}.
|
||||||
@ -1479,10 +1503,10 @@ With given environmental constraints, we can therefore eliminate some failure mo
|
|||||||
|
|
||||||
\paragraph{Operational states.}
|
\paragraph{Operational states.}
|
||||||
Within the field of safety critical engineering, we often encounter
|
Within the field of safety critical engineering, we often encounter
|
||||||
sub-systems that include test or self-test facilities.
|
elements that include test or self-test facilities.
|
||||||
%
|
%
|
||||||
We also encounter degraded performance
|
We also encounter degraded performance
|
||||||
(such as only performing functions in an emergency) and lockout conditions.
|
(such as only performing functions in an emergency) and lockout/emergency conditions.
|
||||||
These can be broadly termed operational states. %, and apply to the
|
These can be broadly termed operational states. %, and apply to the
|
||||||
%functional groups.
|
%functional groups.
|
||||||
%
|
%
|
||||||
@ -1494,10 +1518,9 @@ When the TEST line is activated, it supplies a test signal
|
|||||||
which will validate the circuit. This circuit will have two operational states,
|
which will validate the circuit. This circuit will have two operational states,
|
||||||
NORMAL and TEST mode.
|
NORMAL and TEST mode.
|
||||||
%
|
%
|
||||||
It seems better to apply the operational states to functional groups.
|
It seems better to apply the operational states to {\fgs}.
|
||||||
%
|
%
|
||||||
Functional groups by definition implement functionality, or purpose
|
Functional groupings by definition implement functionality, or purpose, and therefore are the best objects to model
|
||||||
of particular sub-systems, and therefore are the best objects to model
|
|
||||||
operational states.% with.
|
operational states.% with.
|
||||||
|
|
||||||
\paragraph{Inhibit Conditions.}
|
\paragraph{Inhibit Conditions.}
|
||||||
|
Binary file not shown.
Loading…
Reference in New Issue
Block a user