updates after andrew fish pdf with notes on in gmail
This commit is contained in:
parent
489b3448e8
commit
fd38aa0a07
@ -4,7 +4,7 @@
|
||||
#
|
||||
|
||||
|
||||
paper: paper.tex component_failure_modes_definition.tex
|
||||
paper: paper.tex component_failure_modes_definition_paper.tex
|
||||
#latex paper.tex
|
||||
#dvipdf paper pdflatex cannot use eps ffs
|
||||
pdflatex paper.tex
|
||||
|
@ -11,7 +11,7 @@ Mathematical constraints and definitions are made using set theory.
|
||||
|
||||
\section{Introduction}
|
||||
This chapter describes the data types and concepts for the Failure Mode Modular De-composition (FMMD) method.
|
||||
When analysing a safety critical system using the
|
||||
When analysing a safety critical system using
|
||||
this technique, we need clearly defined failure modes for
|
||||
all the components that are used to model the system.
|
||||
These failure modes have a constraint such that
|
||||
@ -31,12 +31,12 @@ build hierarchical bottom-up models of failure mode behaviour.
|
||||
%% Paragraph component and its relationship to its failure modes
|
||||
%%
|
||||
|
||||
\section{ What is a Component ?}
|
||||
\section{ Defining the term `Component' }
|
||||
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=400pt,bb=0 0 437 141,keepaspectratio=true]{component_failure_modes_definition/component.jpg}
|
||||
\includegraphics[width=300pt,bb=0 0 437 141,keepaspectratio=true]{component_failure_modes_definition/component.jpg}
|
||||
% component.jpg: 437x141 pixel, 72dpi, 15.42x4.97 cm, bb=0 0 437 141
|
||||
\caption{A Component and its Failure Modes}
|
||||
\label{fig:component}
|
||||
@ -57,9 +57,16 @@ Thus we can associate a set of faults to this component $ResistorFaultModes=\{OP
|
||||
The UML 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.
|
||||
Also to clearly show that the failure modes are unique events associated with one component,
|
||||
each failure mode is referenced back to only one component.
|
||||
each failure mode is referenced back to only one component.
|
||||
This modelling constraint is due to the fact that even generic components with the same
|
||||
failure mode types, will have different statistical MTTF properties within the same circuitry.
|
||||
%% sharing failure modes arrrgghh so irrelevant
|
||||
%% wrong as well perhaps, as each component will have environmental constraints
|
||||
%% that determine its statistical behaviour. A 1 Meg ohm resistor
|
||||
%% is less stressed than a 100 ohm in the same circuit etc
|
||||
% Perhaps talk here about the failure modes being shared, but by being referenced
|
||||
% by the component ?
|
||||
|
||||
@ -78,6 +85,10 @@ as shown in figure \ref{fig:componentpl}.
|
||||
\label{fig:componentpl}
|
||||
\end{figure}
|
||||
|
||||
Parts in the parts list (bought in parts) will be termed `base~comonents'.
|
||||
Parts derived from base~components may not require parts numbers, and will
|
||||
not require a vendor reference, but must be named.
|
||||
|
||||
|
||||
|
||||
|
||||
@ -91,7 +102,8 @@ Traditional static fault analysis methods work from the top down.
|
||||
They identify faults that can occur in a system, and then work down
|
||||
to see how they could be caused. Some apply statistical tequniques to
|
||||
determine the likelihood of component failures
|
||||
causing specific system level errors (see Bayes theorem \ref{bayes}).
|
||||
causing specific system level errors. For example, Bayes theorem \ref{bayes}, the relation between a conditional probability and its inverse,
|
||||
can be applied to specific failure modes in components and the probability of them causing given system level errors.
|
||||
Another top down technique is to apply cost benifit analysis
|
||||
to determine which faults are the highest priority to fix\cite{FMEA}.
|
||||
The aim of FMMD analysis is to produce complete failure
|
||||
@ -106,12 +118,18 @@ In order to analyse from the bottom-up, we need to take
|
||||
small groups of components from the parts~list that naturally
|
||||
work together to perform a simple function.
|
||||
The components to include in a functional group are chosen by a human, the analyst.
|
||||
We can term this a `Functional~Group' and represent it as a class. When we have a
|
||||
%We can represent the `Functional~Group' as a class.
|
||||
When we have a
|
||||
`Functional~Group' we can look at the failure modes of all the components
|
||||
in it and determine a failure mode model for that group.
|
||||
Or in other words we can determine the failure modes of the functional
|
||||
in it.
|
||||
% and determine a failure mode model for that group.
|
||||
The `Functional~Group' is seen by the analyst as a collection of component failures modes.
|
||||
Each of these failure modes, and optionally combinations of them, are
|
||||
analsyed for their effect on the failure mode behaviour of the `Functional~Group'.
|
||||
From this we can determine a new set of failure modes, the failure modes of the
|
||||
Or in other words we can determine the failure modes of the `Functional~Group'.
|
||||
group. We can now consider the functional group as a sort of super component
|
||||
with a know set of failure modes.
|
||||
with a known set of failure modes.
|
||||
|
||||
|
||||
\subsection{From functional group to newly derived component}
|
||||
@ -137,7 +155,7 @@ We thus have a `new' component, or system building block, but with a known and t
|
||||
fault behaviour.
|
||||
|
||||
The UML representation shows a `functional group' having a one to one relationship with a derived~component.
|
||||
We can represet this using an UML diagram in figure \ref{fig:cfg}
|
||||
We can represent this using an UML diagram in figure \ref{fig:cfg}.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
@ -147,14 +165,25 @@ We can represet this using an UML diagram in figure \ref{fig:cfg}
|
||||
\label{fig:cfg}
|
||||
\end{figure}
|
||||
|
||||
\subsection{Keeping track of the dereived components position in the hierarchy}
|
||||
Using the symbol $\bowtie$ to indicate an analysis process that takes a
|
||||
functional group and converts it into a new component.
|
||||
|
||||
The UML meta model in figure \ref{fig:cfg}, will build a hierarchy of
|
||||
$$ \bowtie ( FG ) \mapsto DerivedComponent $$
|
||||
|
||||
|
||||
|
||||
\subsection{Keeping track of the derived \\ components position in the hierarchy}
|
||||
|
||||
The UML meta model in figure \ref{fig:cfg}, shows the relationships
|
||||
between the classes and sub-classes.
|
||||
In use we will build a hierarchy of
|
||||
objects, with derived~components forming functional~groups, and creating
|
||||
derived components higher up in the structure.
|
||||
The level variable in each Component,
|
||||
indicates the position in the hierarchy. Base or parts~list components
|
||||
have a `level' of 0. Derived~components take a level based on the highest level
|
||||
have a `level' of 0.
|
||||
% I do not know how to make this simpler
|
||||
Derived~components take a level based on the highest level
|
||||
component used to build the functional group it was derived from plus 1.
|
||||
So a derived component built from base level or parts list components
|
||||
would have a level of 1.
|
||||
@ -162,21 +191,21 @@ would have a level of 1.
|
||||
|
||||
|
||||
|
||||
\section{Set Theory Description}
|
||||
|
||||
$$ System \stackrel{has}{\longrightarrow} PartsList $$
|
||||
|
||||
$$ PartsList \stackrel{has}{\longrightarrow} Components $$
|
||||
|
||||
$$ Component \stackrel{has}{\longrightarrow} FailureModes $$
|
||||
|
||||
$$ FunctionalGroup \stackrel{has}{\longrightarrow} Components $$
|
||||
|
||||
Using the symbol $\bowtie$ to indicate an analysis process that takes a
|
||||
functional group and converts it into a new component.
|
||||
|
||||
$$ \bowtie ( FG ) \mapsto DerivedComponent $$
|
||||
|
||||
% \section{Set Theory Description}
|
||||
%
|
||||
% $$ System \stackrel{has}{\longrightarrow} PartsList $$
|
||||
%
|
||||
% $$ PartsList \stackrel{has}{\longrightarrow} Components $$
|
||||
%
|
||||
% $$ Component \stackrel{has}{\longrightarrow} FailureModes $$
|
||||
%
|
||||
% $$ FunctionalGroup \stackrel{has}{\longrightarrow} Components $$
|
||||
%
|
||||
% Using the symbol $\bowtie$ to indicate an analysis process that takes a
|
||||
% functional group and converts it into a new component.
|
||||
%
|
||||
% $$ \bowtie ( FG ) \mapsto DerivedComponent $$
|
||||
%
|
||||
|
||||
|
||||
\section{Unitary State Component Failure Mode sets}
|
||||
@ -216,9 +245,9 @@ the component failure modes in each of its members are unitary~state.
|
||||
Thus if the failure modes of $F$ are unitary~state, we can say $F \in U$.
|
||||
|
||||
|
||||
\section{Component failure modes : Unitary State example}
|
||||
\section{Component failure modes:\\ Unitary State example}
|
||||
|
||||
A component with an obvious set of ``unitary~state'' failure modes is the electrical resistor.
|
||||
An example of a component with an obvious set of ``unitary~state'' failure modes is the electrical resistor.
|
||||
|
||||
Electrical resistors can fail by going OPEN or SHORTED.
|
||||
|
||||
@ -236,9 +265,9 @@ therefore
|
||||
$$ FM(R) \in U $$
|
||||
|
||||
|
||||
We can make this a general case by taking a set $F$ (where $f1, f2 \in F$) representing a collection
|
||||
We can make this a general case by taking a set $F$ (where $f_1, f_2 \in F$) representing a collection
|
||||
of component failure modes.
|
||||
We can define a boolean function {\ensuremath{\mathcal{ACTIVE()}}} that returns
|
||||
We can define a boolean function {\ensuremath{\mathcal{ACTIVE}}} that returns
|
||||
whether a fault mode is active (true) or dormant (false).
|
||||
|
||||
We can say that if any pair of fault modes is active at the same time, then the failure mode set is not
|
||||
@ -272,16 +301,15 @@ the state where the component is working perfectly or `OK' (i.e. operating with
|
||||
We are interested only in ways in which it can fail.
|
||||
By definition while all components in a system are `working perfectly'
|
||||
that system will not exhibit faulty behaviour.
|
||||
Thus the statistical sample space $\Omega$ for a component or derived~component $K$ is
|
||||
Thus the statistical sample space $\Omega$ for a component or derived~component $C$ is
|
||||
%$$ \Omega = {OK, failure\_mode_{1},failure\_mode_{2},failure\_mode_{3} ... failure\_mode_{N} $$
|
||||
$$ \Omega(K) = \{OK, failure\_mode_{1},failure\_mode_{2},failure\_mode_{3}, \ldots ,failure\_mode_{N}\} $$
|
||||
The failure mode set $F$ for a given component or derived~component $K$
|
||||
$$ \Omega(C) = \{OK, failure\_mode_{1},failure\_mode_{2},failure\_mode_{3}, \ldots ,failure\_mode_{N}\} $$
|
||||
The failure mode set $F$ for a given component or derived~component $C$
|
||||
is therefore
|
||||
$$ F = \Omega(K) \backslash OK $$
|
||||
$$ F = \Omega(C) \backslash OK $$
|
||||
|
||||
The $OK$ statistical case is the largest in probability, and is therefore
|
||||
of interest when analysing systems that have failed using techniques
|
||||
such as bayes theorem to determine the likelyhood of the failure source.
|
||||
of interest when analysing systems from a statistical perspective.
|
||||
|
||||
|
||||
\vspace{40pt}
|
||||
|
Loading…
Reference in New Issue
Block a user