Sunday 25th April 2010 Edits
This commit is contained in:
parent
22386efd15
commit
38ffad59b5
@ -1,15 +1,23 @@
|
||||
|
||||
\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.
|
||||
%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}
|
||||
|
||||
When analysing a safety critical system using the
|
||||
FMMD 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 compoent failure modes must be mutually exclusive.
|
||||
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
|
||||
@ -21,7 +29,7 @@ Mathematical constraints and definitions are made using set theory.
|
||||
%% Paragraph component and its relationship to its failure modes
|
||||
%%
|
||||
|
||||
\subsection{ What is a Component ?}
|
||||
\section{ What is a Component ?}
|
||||
|
||||
|
||||
Let us first define a component. This is anything we use to build a
|
||||
@ -42,7 +50,7 @@ structure with its failure modes.
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=400pt,bb=0 0 437 141,keepaspectratio=true]{./component.jpg}
|
||||
\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}
|
||||
@ -63,7 +71,7 @@ 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]{./componentpl.jpg}
|
||||
\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}
|
||||
@ -76,7 +84,7 @@ as shown in figure \ref{fig:componentpl}.
|
||||
%% Paragraph using failure modes to build from bottom up
|
||||
%%
|
||||
|
||||
\subsection{Fault Mode Analysis, top down or 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
|
||||
@ -112,12 +120,27 @@ We can represet this in a UML diagram see figure \ref{fig:cfg}
|
||||
|
||||
\begin{figure}[h]
|
||||
\centering
|
||||
\includegraphics[width=400pt,bb=0 0 712 235,keepaspectratio=true]{./cfg.jpg}
|
||||
\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}
|
||||
|
||||
\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 Component $$
|
||||
|
||||
|
||||
%
|
||||
% \subsection{Systems, functional groups, sub-systems and failure modes}
|
||||
@ -280,7 +303,7 @@ We can represet this in a UML diagram see figure \ref{fig:cfg}
|
||||
% % \end{figure}
|
||||
|
||||
|
||||
\subsection{Unitary State Component Failure Mode sets}
|
||||
\section{Unitary State Component Failure Mode sets}
|
||||
|
||||
An important factor in defining a set of failure modes is that they
|
||||
should be as clearly defined as possible.
|
||||
@ -319,7 +342,7 @@ 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$.
|
||||
|
||||
|
||||
\subsection{Component failure modes : Unitary State example}
|
||||
\section{Component failure modes : Unitary State example}
|
||||
|
||||
A component with simple ``unitary~state'' failure modes is the electrical resistor.
|
||||
|
||||
@ -352,7 +375,7 @@ for the failure mode set $C$ to exists in the family of sets $U$
|
||||
|
||||
|
||||
|
||||
\subsection{Component Failure Modes and Statistical Sample Space}
|
||||
\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.
|
||||
Here the outcomes we are interested in are the failure modes
|
||||
@ -369,24 +392,67 @@ The failure mode set for a given component or sub-system $F$
|
||||
is therefore
|
||||
$$ F = \Omega(K) \backslash OK $$
|
||||
|
||||
\clearpage
|
||||
|
||||
THIS SHOULD BE IN A DIFFERENT CHAPTER
|
||||
|
||||
\section{Current Methods for Safety Critical Analysis}
|
||||
|
||||
|
||||
\subsection{Deterministic Approach}
|
||||
\paragraph{NOT WRITTEN YET PLEASE IGNORE}
|
||||
No single component fault may lead to a dangerous condition.
|
||||
EN298 En230 etc
|
||||
|
||||
\subsection{Bayes Theorem}
|
||||
\paragraph{NOT WRITTEN YET PLEASE IGNORE}
|
||||
\paragraph{NOT WRITTEN YET PLEASE IGNORE}
|
||||
\label{bayes}
|
||||
Describe application - likely hood of faults being the cause of symptoms -
|
||||
probablistic approach - no direct causation paths to the higher~abstraction fault mode.
|
||||
Often for instance a component in a module within a module within a module etc
|
||||
that has a probability of causing a SYSTEM level fault.
|
||||
|
||||
Used in FTA\cite{NASA}\cite{NUK}. Problems, difficult to get reliable stats
|
||||
Used in FTA\cite{NASA}\cite{NUK}.
|
||||
The idea being that probabilities can be assigned to components
|
||||
failing, causing system level errors.
|
||||
|
||||
Problems, difficult to get reliable stats
|
||||
for probability to cause because of small sample numbers...
|
||||
|
||||
FMMD approach can by traversing down the tree use known component failure figures
|
||||
to
|
||||
to get {\em accurate} probabilities and potential causes.
|
||||
%$$ c1 \cap c2 \eq \emptyset | c1 \neq c2 \wedge c1,c2 \in C \wedge C \in U $$
|
||||
|
||||
%Thus if the failure~modes are pairwaise mutually exclusive they qualify for inclusion into the
|
||||
%unitary~state set family.
|
||||
|
||||
\subsection{ Saftey Integrity Level Analysis }
|
||||
\paragraph{NOT WRITTEN YET PLEASE IGNORE}
|
||||
\label{sil}
|
||||
This technique looks at all components in the parts list
|
||||
and asks what the effect of the component failing will be.
|
||||
Note that particular failure modes of the compoent are not considered.
|
||||
The component can fail in any of its failure modes from the perspective of this analysis.
|
||||
The analyst has to make a choice between four conditions:
|
||||
|
||||
\begin{itemize}
|
||||
\item sd - A safe fault that is detected by an automated system
|
||||
\item su - A safe fault that is undetected by an automated system
|
||||
\item dd - A potentially dangerous fault that is detected by an automated system
|
||||
\item du - A potentially dangerous fault that is not detected by an automated system
|
||||
\end{itemize}
|
||||
Actually this is almost how sil analysis is done, because
|
||||
the base components are listed
|
||||
and their failure result as either sd su dd du
|
||||
|
||||
A formula is then applied according to the system architecture 1oo1 2oo3 3oo3 etc
|
||||
|
||||
What is not done is the probability for all these conditions, the sil analysis
|
||||
person simple has to decide which it is.
|
||||
Another fault in this is that it is very difficult to
|
||||
extract meaning ful stats
|
||||
for how likely the detection systems are to pick the fault up, or even to introduce a fault of their own.
|
||||
|
||||
\subsection{Tests of Hypotheses and Significance}
|
||||
\paragraph{NOT WRITTEN YET PLEASE IGNORE}
|
||||
Linked in with Bayes theorem
|
||||
@ -400,3 +466,7 @@ but how do you corrollate that with unshielded suppressed contactors...
|
||||
Maybe looking at the equipment and seeing if there is a 5\%
|
||||
level of the error being caused ?
|
||||
i.e. using it to search for these conditions ?
|
||||
|
||||
|
||||
Actually this could be used to refine the SIL method \ref{sil}
|
||||
and give probabilities for the four conditions.
|
||||
|
Loading…
Reference in New Issue
Block a user