robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

after Friday meeting with Andrew Fish

Browse Source
This commit is contained in:
Robin 2010-05-08 10:53:39 +01:00
parent ba16d8c31e
commit f30f435de5
3 changed files with 79 additions and 35 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

BIN
component_failure_modes_definition/cfg.dia
View File

Binary file not shown.

BIN
component_failure_modes_definition/cfg.jpg
View File

Binary file not shown.
Side by Side Swipe Overlay

Before

Width:  |  Height:  |  Size: 19 KiB

After

Width:  |  Height:  |  Size: 22 KiB

112
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -47,8 +47,13 @@ failure rates)\cite{mil1991}. For instance, a simple resistor is generally consi
to fail in two ways, it can go open circuit or it can short. to fail in two ways, it can go open circuit or it can short.
Thus we can associate a set of faults to this component $ResistorFaultModes=\{OPEN, SHORT\}$. Thus we can associate a set of faults to this component $ResistorFaultModes=\{OPEN, SHORT\}$.
The UML diagram in figure The UML diagram in figure
\ref{fig:component} shows a component as a simple data \ref{fig:component} shows a component as a data
structure with its failure modes. 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.
% Perhaps talk here about the failure modes being shared, but by being referenced
% by the component ?
\begin{figure}[h] \begin{figure}[h]
@ -59,14 +64,6 @@ structure with its failure modes.
\label{fig:component} \label{fig:component}
\end{figure} \end{figure}
% \begin{figure}[h+]
% \centering
% \includegraphics[width=400pt,bb=0 0 433 68,keepaspectratio=true]{component_failure_modes_definition/component.jpg}
% % component.jpg: 433x68 pixel, 72dpi, 15.28x2.40 cm, bb=0 0 433 68
% \caption{A Component and its failure modes}
% \label{fig:component}
% \end{figure}
A product naturally consists of many components and these are traditionally A product naturally consists of many components and these are traditionally
kept in a `parts list'. For safety critical product this is a usually formal document kept in a `parts list'. For safety critical product this is a usually formal document
and is used by quality inspectors to ensure the correct parts are being fitted. and is used by quality inspectors to ensure the correct parts are being fitted.
@ -96,39 +93,77 @@ determine the likelihood of component failures
causing specific system level errors (see Bayes theorem \ref{bayes}). causing specific system level errors (see Bayes theorem \ref{bayes}).
Another top down technique is to apply cost benifit analysis Another top down technique is to apply cost benifit analysis
to determine which faults are the highest priority to fix\cite{FMEA}. to determine which faults are the highest priority to fix\cite{FMEA}.
The aim of this study 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 component failure modes. starting, where possible with known component failure modes.
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 from the parts~list that naturally
work together to perform a simple function. work together to perform a simple function.
The components to for the functional groups are chosen by a human, the analyst.
We can term this a `Functional~Group'. When we have a We can term this a `Functional~Group'. When we have a
`Functional~Group' we can look at the failure modes of all the components `Functional~Group' we can look at the failure modes of all the components
in it and decide how these will affect the Group. in it and decide how these will affect the Group.
Or in other words we can determine the failure modes of the functional Or in other words we can determine the failure modes of the functional
group. These new failure modes are derived from the functional group, we can therefore call group. By working from the bottom up we can ensure that
these `derived failure modes'. all component failure modes must be considered. A top down approach
We now have something very useful, because could miss individual failure modes of components.
we can now treat this functional group as a component with a known set of failure modes.
This newly derived component can be used as a higher level
building block for the system we are analysing. \subsection{From functional group to newly derived component}
Derived components, can be used
to form higher level functional groups. The process for taking a functional~group, considering
This process can continue until have build a hierarcy that converges to a failure model of the entire system. all the failure modes of all the componentsin figure \ref{fig:cfg} in it,
To differentiate the components derived from functional groups, we can and analysing these is called `symptom abstraction' and
add a new attribute to the class `Component', that of analysis is dealt with in detail in chapter \ref{symptom_abstraction}.
level. The UML representation shows a `functional group' having a one to one relationship with a derived component.
In terms of our UML model the symptom abstraction process takes a functional~group,
and creates a new derived component from it.
To do this it first creates
a new set of failure modes, representing the fault behaviour
of the functional group. This is a human process and the analyst
will consider all the failure modes of the components in the functional
group.
These new failure modes are derived from the functional group, we can therefore 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
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 represet this using an UML diagram in figure \ref{fig:cfg}
\begin{figure}[h] \begin{figure}[h]
\centering \centering
\includegraphics[width=400pt,bb=0 0 712 235,keepaspectratio=true]{component_failure_modes_definition/cfg.jpg} \includegraphics[width=400pt,bb=0 0 712 286,keepaspectratio=true]{./cfg.jpg}
% cfg.jpg: 712x205 pixel, 72dpi, 25.12x7.23 cm, bb=0 0 712 205 % cfg.jpg: 712x286 pixel, 72dpi, 25.12x10.09 cm, bb=0 0 712 286
\caption{Components Derived from Functional Groups} \caption{UML Meta model for FMMD hierarchy}
\label{fig:cfg} \label{fig:cfg}
\end{figure} \end{figure}
\clearpage %
% \begin{figure}[h+]
% \centering
% \includegraphics[width=400pt,bb=0 0 712 235,keepaspectratio=true]{component_failure_modes_definition/cfg.jpg}
% % cfg.jpg: 712x205 pixel, 72dpi, 25.12x7.23 cm, bb=0 0 712 205
% \caption{Components Derived from Functional Groups}
% \label{fig:cfg}
% \end{figure}
\subsection{Keeping track of the dereived components position in the hierarchy}
The UML meta model in figure \ref{fig:cfg}, 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
component used to build the functional group it was derived from plus 1.
So a derived component built from base lavel or parts list components
would have a level of 1.
%\clearpage
\section{Set Theory Description} \section{Set Theory Description}
$$ System \stackrel{has}{\longrightarrow} PartsList $$ $$ System \stackrel{has}{\longrightarrow} PartsList $$
@ -362,17 +397,26 @@ therefore
$$ FM(R) \in U $$ $$ FM(R) \in U $$
We can make this a general case by taking a set $C$ (where $c1, c2 \in C$) representing a collection We can make this a general case by taking a set $F$ (where $f1, f2 \in F$) representing a collection
of component failure modes. of component failure modes.
We can now state that We can define a boolean function {\ensuremath{\mathcal{ACTIVE()}}} that returns
whether the 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
unitary state:
we state this formally
\begin{equation} \begin{equation}
c1 \cap c2 \neq \emptyset | c1 \neq c2 \wedge c1,c2 \in C \wedge C \not\in U \forall f_1,f_2 \in F \dot ( f_1 \neq f_2 \wedge \mathcal{ACTIVE}({f_1}) \wedge \mathcal{ACTIVE}({f_2}) ) \implies F \not\in U
\end{equation} \end{equation}
%
% \begin{equation}
% c1 \cap c2 \neq \emptyset | c1 \neq c2 \wedge c1,c2 \in C \wedge C \not\in U
% \end{equation}
That is to say that it is impossible that any pair of failure modes can be active at the same time That is to say that it is impossible that any pair of failure modes can be active at the same time
for the failure mode set $C$ to exists in the family of sets $U$ for the failure mode set $F$ to exists in the family of sets $U$
Note where that are more than two failure~modes, Note where that are more than two failure~modes,
by banning pairs from being active at the same time by banning pairs from being active at the same time
@ -383,8 +427,8 @@ we have banned larger combinations as well.
\section{Component Failure Modes and Statistical Sample Space} \section{Component Failure Modes and Statistical Sample Space}
%\paragraph{NOT WRITTEN YET PLEASE IGNORE} %\paragraph{NOT WRITTEN YET PLEASE IGNORE}
A sample space is defined as the set of all possible outcomes. A sample space is defined as the set of all possible outcomes.
Here the outcomes we are interested in are the failure modes For a component this set of all possible outcomes are its normal correct
of the component. operating state and all its failure modes.
When dealing with failure modes, we are not interested in When dealing with failure modes, we are not interested in
the state where the component is working perfectly or `OK' (i.e. operating with no error). the state where the component is working perfectly or `OK' (i.e. operating with no error).
We are interested only in ways in which it can fail. We are interested only in ways in which it can fail.