288 lines
12 KiB
TeX
288 lines
12 KiB
TeX
|
|
\abstract{ This chapter defines what is meant by the terms
|
|
components, 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.
|
|
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.
|
|
When analysing a safety critical system using the
|
|
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
|
|
the component failure modes must be mutually exclusive.
|
|
When this constraint is complied with we can use the FMMD process to
|
|
build hierarchical bottom-up models of failure mode behaviour.
|
|
%This and the definition of a component are
|
|
%described in this chapter.
|
|
%When building a system from components,
|
|
%we should be able to find all known failure modes for each component.
|
|
%For most common electrical and mechanical components, the failure modes
|
|
%for a given type of part can be obtained from standard literature\cite{mil1991}
|
|
%\cite{mech}. %The failure modes for a given component $K$ form a set $F$.
|
|
|
|
|
|
%%
|
|
%% Paragraph component and its relationship to its failure modes
|
|
%%
|
|
|
|
\section{ What is a Component ?}
|
|
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=400pt,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}
|
|
\end{figure}
|
|
|
|
Let us first define a component. This is anything 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
|
|
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
|
|
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\}$.
|
|
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.
|
|
% Perhaps talk here about the failure modes being shared, but by being referenced
|
|
% by the component ?
|
|
|
|
|
|
|
|
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
|
|
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}.
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=400pt,bb=0 0 712 68,keepaspectratio=true]{component_failure_modes_definition/componentpl.jpg}
|
|
% componentpl.jpg: 712x68 pixel, 72dpi, 25.12x2.40 cm, bb=0 0 712 68
|
|
\caption{Parts List of Components}
|
|
\label{fig:componentpl}
|
|
\end{figure}
|
|
|
|
|
|
|
|
|
|
%%
|
|
%% Paragraph using failure modes to build from bottom up
|
|
%%
|
|
|
|
\section{Fault Mode Analysis, top down or bottom up?}
|
|
|
|
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}).
|
|
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
|
|
models of safety critical systems from the bottom-up,
|
|
starting, where possible with known component failure modes.
|
|
|
|
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
|
|
could miss individual failure modes of components.
|
|
|
|
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
|
|
`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
|
|
group. We can now consider the functional group as a sort of super component
|
|
with a know set of failure modes.
|
|
|
|
|
|
\subsection{From functional group to newly derived component}
|
|
|
|
The process for taking a functional~group, considering
|
|
all the failure modes of all the components in the group,
|
|
and analysing it is called `symptom abstraction' and
|
|
is dealt with in detail in chapter \ref{symptom_abstraction}.
|
|
|
|
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 to do this the analyst
|
|
%must consider all the failure modes of the components in the functional
|
|
%group.
|
|
The newly created derived~component requires a set of failure modes of its own.
|
|
These failure modes are the failure mode behaviour of the functional group that it was derived from.
|
|
Because these new failure modes were determined from a derived component 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
|
|
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}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=400pt,bb=0 0 712 286,keepaspectratio=true]{./cfg.jpg}
|
|
% cfg.jpg: 712x286 pixel, 72dpi, 25.12x10.09 cm, bb=0 0 712 286
|
|
\caption{UML Meta model for FMMD hierarchy}
|
|
\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 level or parts list components
|
|
would have a level of 1.
|
|
%\clearpage
|
|
|
|
|
|
|
|
\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}
|
|
|
|
\paragraph{Design Descision/Constraint}
|
|
An important factor in defining a set of failure modes is that they
|
|
should be as clearly defined as possible.
|
|
It should not be possible for instance for
|
|
a component to have two or more failure modes active at once.
|
|
Having a set of failure modes where $N$ modes could be active simultaneously
|
|
would mean having to consider an additional $2^N-1$ failure mode scenarios.
|
|
Should a component be analysed and simultaneous failure mode cases exit,
|
|
the combinations could be represented by new failure modes, or
|
|
the component should be considered from a fresh perspective,
|
|
perhaps considering it as several smaller components
|
|
within one package.
|
|
|
|
|
|
|
|
|
|
|
|
\begin{definition}
|
|
A set of failure modes where only one fault mode
|
|
can be active at a time is termed a `unitary~state' failure mode set.
|
|
%This is termed the $U$ set thoughout this study.
|
|
This corresponds to the `mutually exclusive' definition in
|
|
probability theory\cite{probandstat}.
|
|
\end{definition}
|
|
|
|
We can define a function $FM()$ to
|
|
take a given component $K$ and return its set of failure modes $F$.
|
|
|
|
$$ FM : K \mapsto F $$
|
|
|
|
We can further define a set $U$ which is a set of sets of failure modes, where
|
|
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}
|
|
|
|
A component with an obvious set of ``unitary~state'' failure modes is the electrical resistor.
|
|
|
|
Electrical resistors can fail by going OPEN or SHORTED.
|
|
|
|
For a given resistor R we can apply the
|
|
the function $FM$ to find its set of failure modes thus $ FM(R) = \{R_{SHORTED},R_{OPEN}\} $.
|
|
A resistor cannot fail with both conditions open and short active at the same time ! The conditions
|
|
OPEN and SHORT are thus mutually exclusive.
|
|
Because of this the failure mode set $F=FM(R)$ is `unitary~state'.
|
|
|
|
|
|
Thus
|
|
|
|
$$ R_{SHORTED} \cap R_{OPEN} = \emptyset $$
|
|
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
|
|
of component failure modes.
|
|
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
|
|
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 U
|
|
\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
|
|
for the failure mode set $F$ to exist in the family of sets $U$.
|
|
Note where that 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{Component Failure Modes and Statistical Sample Space}
|
|
%\paragraph{NOT WRITTEN YET PLEASE IGNORE}
|
|
A sample space is defined as the set of all possible outcomes.
|
|
For a component in FMMD analysis, this set of all possible outcomes is its normal correct
|
|
operating state and all its failure modes.
|
|
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).
|
|
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
|
|
%$$ \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$
|
|
is therefore
|
|
$$ F = \Omega(K) \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.
|
|
|
|
|
|
\vspace{40pt}
|