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

abstract/into

Browse Source
This commit is contained in:
Robin 2010-06-26 15:59:33 +01:00
parent f7cdb7e3ff
commit 70c219721a
1 changed files with 50 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

56
symptom_ex_process/symptom_ex_process.tex
View File

@ -7,8 +7,11 @@ In failure mode analysis, it is essential to
know the failure modes of the sub-systems and components used.
This paper outlines a technique for determining the failure modes of a sub-system given
its components.
This chapter describes a process for taking a functional group of components, applying FMEA analysis and then determining how that functional group can fail.
%
This paper describes a process for taking a functional~group of components,
applying FMEA analysis on all the component failure modes possible in that functional~group,
and then determining how that functional group can fail.
%
With this information, we can treat the functional group
as a component in its own right.
This new component is a derived component.
@ -34,16 +37,57 @@ of FTA\cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets\cite{nucfta} ar
Also statistical reliability/probability of failure~on~demand\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced
automatically, where component failure mode statistics are available\cite{mil1991}.
%
This paper focuses on the process of building the blocks, that are key to creating an FMMD hierarchy.
%
This paper focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy.
\end{abstract}
}
{}
{
\section{Introduction}
In failure mode analysis, it is essential to
know the failure modes of the sub-systems and components used.
This paper outlines a technique for determining the failure modes of a sub-system given
its components.
%
This chapter describes a process for taking a functional group of components,
applying FMEA analysis on all the component failure modes possible in that functional~group,
and then determining how that functional group can fail.
%
%
With this information, we can treat the functional group
as a component in its own right.
This new component is a derived component.
For a top down technique this would correspond to a low~level sub-system.
%The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model.
%
Once the failure modes have been determined for a sub-system/derived~component,
this derived component can be combined with others to form functional groups
to model
higher level sub-systems/derived~components.
%
In this way a hierarchy to represent the fault behaviour
of a system can be built from the bottom~up. This process can continue
until there is a complete hierarchy representing the failure mode
behaviour of the entire system under analysis.
%FMMD hierarchy
Using the FMMD technique the hierarchy is built from the bottom up to ensure complete failure mode coverage.
Because the process is bottom-up, syntax checking and tracking can ensure that
no component failure mode can be overlooked.
Once a hierarchy is in place it can be converted into a fault data model.
%
From the fault data model, automatic generation
of FTA\cite{nasafta} (Fault Tree Analysis) and mimimal cuts sets\cite{nucfta} are possible.
Also statistical reliability/probability of failure~on~demand\cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced
automatically, where component failure mode statistics are available\cite{mil1991}.
%
This chapter focuses on the process of building the blocks, the symptom extraction or abstraction process, that is key to creating an FMMD hierarchy.
}
%\clearpage
\section{Introduction}
\subsection{Top Down or natural trouble shooting}
It is interesting here to look at the `natural' trouble shooting process.