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

proof reading by JMC,english and spelling

Browse Source
This commit is contained in:
Robin 2010-06-12 07:56:09 +01:00
parent 1e3badc308
commit 66fd3ba28d
1 changed files with 29 additions and 16 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

45
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -3,14 +3,27 @@
\ifthenelse {\boolean{paper}}
{
\abstract{ This chapter defines what is meant by the terms
\abstract{
This paper defines what is meant by the terms
components, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes.
%The application of Bayes theorem in current methodologies, and
%the suitability of the `null hypothesis' or `P' value statistical approach
%are discussed.
The general concept of the cardinality constrained powerset is introduced
and calculations for it corrected for the `unitary state' fault mode conditions.
Data types and their relationships are described using UML.
Mathematical constraints and definitions are made using set theory.}
}
{
\section{Overview}
This chapter defines what is meant by the terms
components, derived~components, functional~groups, component fault modes and `unitary~state' component fault modes.
The general concept of the cardinality constrained powerset is introduced
and calculations for it corrected for the `unitary state' fault mode conditions.
Data types and their relationships are described using UML.
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.
@ -45,7 +58,7 @@ build hierarchical bottom-up models of failure mode behaviour.
\label{fig:component}
\end{figure}
Let us first define a component. This is anything we use to build a
Let us first define a component. This is anything which we use to build a
product or system with. This could be something quite complicated
like an integrated microcontroller, or quite simple like the humble resistor.
We can define a
@ -53,7 +66,7 @@ component by its name, a manufacturers part number and perhaps
a vendors reference number.
What these components all have in common is that they can fail, and fail in
a number of well defined ways. For common components
there is established literature for the failure modes for the system designer consider (often with accompanying statistical
there is established literature for the failure modes for the system designer to consider (often with accompanying statistical
failure rates)\cite{mil1991}. For instance, a simple resistor is generally considered
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\}$.
@ -63,7 +76,7 @@ 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 being referenced back to only one component.
This modelling constraint is due to the fact that even generic components with the same
failure mode types, may have different statistical MTTF properties within the same
circuitry\footnote{For example, consider resistors one of high resistance and one low.
@ -79,7 +92,7 @@ The lower resistance part will draw more current and therefore have a statistica
A product naturally consists of many components and these are traditionally
kept in a `parts list'. For safety critical product this is usually a formal document
kept in a `parts list'. For a safety critical product this is usually a formal document
and is used by quality inspectors to ensure the correct parts are being fitted.
For our UML diagram the parts list is simply a collection of components
as shown in figure \ref{fig:componentpl}.
@ -107,11 +120,11 @@ not require a vendor reference, but must be named.
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
to see how they could be caused. Some apply statistical techniques to
determine the likelihood of component failures
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
Another top down technique is to apply cost benefit analysis
to determine which faults are the highest priority to fix\cite{FMEA}.
The aim of FMMD analysis is to produce complete failure
models of safety critical systems from the bottom-up,
@ -133,7 +146,7 @@ and from this determine the failure modes of all the components that belong to i
% and determine a failure mode model for that group.
The `Functional~Group' as used by the analyst is 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'.
analysed 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
`Functional~Group'.
@ -166,7 +179,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 represent this using an UML diagram in figure \ref{fig:cfg}.
We can represent this using a UML diagram in figure \ref{fig:cfg}.
Using the symbol $\bowtie$ to indicate the analysis process that takes a
functional group and converts it into a new component.
@ -190,7 +203,7 @@ 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,
The level variable in each component,
indicates the position in the hierarchy. Base or parts~list components
have a `level' of 0.
% I do not know how to make this simpler
@ -295,6 +308,8 @@ 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
unitary state:
we state this formally
\begin{equation}
\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 \mathcal{U}
\end{equation}
@ -311,8 +326,6 @@ Note where there are more than two failure~modes,
by banning any pairs from being active at the same time,
we have banned larger combinations as well.
\section{Handling Simultaneous Component Faults}
For some integrity levels of static analysis there is a need to consider not only single
@ -330,7 +343,7 @@ and S itself.
In order to consider combinations for the set S where the number of elements in each sub-set of S is $N$ or less, a concept of the `cardinality constrained powerset'
is proposed and described in the next section.
\pagebreak[4]
\pagebreak[1]
\subsection{Cardinality Constrained Powerset }
\label{ccp}
@ -394,7 +407,7 @@ for each component in the functional group under analysis.
Note we must sequentially subtract using combinations above 1 up to the cardinality constraint.
For example, say
the cardinality constraint was 3, we would need to subtract both
$|{n \choose 2}|$ and $|{n \choose 3}|$.
$|{n \choose 2}|$ and $|{n \choose 3}|$ for each component in the functional~group.
\subsubsection{Example: Two Component functional group \\ cardinality Constraint of 2}
@ -478,9 +491,9 @@ Expanding the combination in equation \ref{eqn:correctedccps}
\end{equation}
Equation \ref{eqn:correctedccps2} is useful for an automated tool that
would verify that a `N' simultaneous failures model had complete failure mode coverage.
would verify that an `N' simultaneous failures model had complete failure mode coverage.
By knowing how many test cases should be covered, and checking the cardinality
associated with the test cases, complete coverage would be confirmed.
associated with the test cases, complete coverage would be verified.
\pagebreak[4]