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

Evening edit...

Browse Source
This commit is contained in:
Robin Clark 2011-01-17 20:00:07 +00:00
parent 3d1bb83b25
commit 64165962c6
5 changed files with 29 additions and 27 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -338,7 +338,7 @@ fm : \mathcal{FG} \rightarrow \mathcal{F}
\section{Unitary State Component Failure Mode sets} \section{Unitary State Component Failure Mode sets}
\label{sec:unitarystate}
\paragraph{Design Descision/Constraint} \paragraph{Design Descision/Constraint}
An important factor in defining a set of failure modes is that they An important factor in defining a set of failure modes is that they
should represent the failure modes as simply and minimally as possible. should represent the failure modes as simply and minimally as possible.

2
fmmd_concept/fmmd_concept.tex
View File

@ -1215,7 +1215,7 @@ for a single base~component failure mode minimal cut set~\cite{nucfta}.
\subsection{Aims of FMMD Methodology} \subsection{Aims of FMMD Methodology}
\label{sec:aims}
Taking the four current failure mode methodologies into consideration, and comparing them to the proposed FMMD methodology, the following wish list or aims can be stated. Taking the four current failure mode methodologies into consideration, and comparing them to the proposed FMMD methodology, the following wish list or aims can be stated.
\begin{itemize} \begin{itemize}

19
symptom_ex_process/algorithm.tex
View File

@ -6,8 +6,8 @@
The algorithm for {\em symptom extraction} is described in The algorithm for {\em symptom extraction} is described in
this section this section
%describes the symptom abstraction process %describes the symptom abstraction process
using set theory. using set theory and procedural descriptions.
%
The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$ The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$
and converts it to a derived~component/sub-system $DC$. and converts it to a derived~component/sub-system $DC$.
%The sub-system $SS$ is a collection %The sub-system $SS$ is a collection
@ -15,7 +15,8 @@ and converts it to a derived~component/sub-system $DC$.
Note that Note that
$DC$ is a derived component at a higher level of fault analysis abstraction $DC$ is a derived component at a higher level of fault analysis abstraction
than the functional~group from which it was derived. than the functional~group from which it was derived.
Thus, it can be treated %Thus,
$DC$ can be treated
as a component with a known set of failure modes. as a component with a known set of failure modes.
@ -55,7 +56,7 @@ naturally formed with the abstraction levels increasing with each tier.
The algorithm, represented by the symbol `$\bowtie$', has been broken down into five consecutive stages. The algorithm, represented by the symbol `$\bowtie$', has been broken down into five consecutive stages.
%These are described using the Algorithm environment in the next section \ref{algorithms}. %These are described using the Algorithm environment in the next section \ref{algorithms}.
By defining the process and describing it using set theory, constraints and By defining the process and describing it using set theory. Constraints and
verification checks in the process are stated formally. verification checks in the process are stated formally.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -82,7 +83,7 @@ $$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
\end{algorithmic} \end{algorithmic}
\end{algorithm} \end{algorithm}
The symptom abstraction methodology allows us to take a functional group of components, The symptom abstraction process allows us to take a functional group of components,
analyse the failure analyse the failure
mode behaviour and create a new entity, a derived~component, that has its own set of failure modes. mode behaviour and create a new entity, a derived~component, that has its own set of failure modes.
The checks and constraints applied in the algorithm ensure that all component failure The checks and constraints applied in the algorithm ensure that all component failure
@ -179,7 +180,7 @@ given by
$$ dtc(F) = TC $$ $$ dtc(F) = TC $$
The function \textbf{chosen} means that the failure modes for a particular test case have been chosen by In algorithm \ref{alg2}, the function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes) a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes)
The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component. The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component.
\ifthenelse {\boolean{paper}} \ifthenelse {\boolean{paper}}
@ -187,7 +188,7 @@ The function \textbf{unitarystate} means that all test cases can have no pairs o
%% perhaps ref a paper here XXXXX %% perhaps ref a paper here XXXXX
} }
{ {
This is discussed in section \ref{unitarystate}. This is discussed in section \ref{sec:unitarystate}.
} }
%% %%
%% Algorithm 2 %% Algorithm 2
@ -337,9 +338,11 @@ The analysis is primarily a human activity.
Each test case is examined in detail. Each test case is examined in detail.
% %
% %
Ideally calculations or simulations Calculations or simulations
are performed to determine how the failure modes in each test case will are performed to determine how the failure modes in each test case will
affect the functional~group. affect the functional~group.
Ideally field and formal physical testing data should be used in addition
where possible.
% %
When the all the test cases have been analysed When the all the test cases have been analysed
we will have a `result' for each `test case'. we will have a `result' for each `test case'.

18
symptom_ex_process/process.tex
View File

@ -3,14 +3,14 @@
% TO DO: separate these two: % TO DO: separate these two:
\paragraph{Symptom Extraction Objective} \paragraph{Symptom Extraction Objective.}
The objective of `symptom abstraction' is to analyse the functional~group and find The objective of `symptom abstraction' is to analyse the functional~group and find
how it can fail how it can fail
when specified components within it fail. when specified components within it fail.
Once we know how a functional~group can fail, we can treat it as a component or sub-system Once we know how a functional~group can fail, we can treat it as a component or sub-system
with its own set of failure modes. with its own set of failure modes.
\paragraph{FMEA applied to the Functional Group} \paragraph{FMEA applied to the Functional Group.}
As the functional~group contains a set of components, the failure~modes As the functional~group contains a set of components, the failure~modes
that we have to consider are all the failure modes of its components, as that we have to consider are all the failure modes of its components, as
developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$. developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$.
@ -27,7 +27,7 @@ the test case conditions, for each test case.
The goal of the process is to produce a set of failure modes from the perspective of the functional~group. The goal of the process is to produce a set of failure modes from the perspective of the functional~group.
% %
\paragraph{Environmental Conditions or Applied States} \paragraph{Environmental Conditions or Applied States.}
Each test case must be considered for all applied/operational states and Each test case must be considered for all applied/operational states and
%in the for the case of each applied states or %in the for the case of each applied states or
@ -52,7 +52,7 @@ examine environmentally sourced common mode failure scenarios.
%%- change due to enviromental factors. %%- change due to enviromental factors.
%%- %%-
\paragraph{Symptom Identification} \paragraph{Symptom Identification.}
When all `test~cases' have been analysed, a second phase can be actioned. % applied. When all `test~cases' have been analysed, a second phase can be actioned. % applied.
% %
This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system. This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system.
@ -66,7 +66,7 @@ will both cause the same failure; $no\_sound$ !
\paragraph{Collection of Symptoms} \paragraph{Collection of Symptoms.}
Looking at the functional group perspective failure modes, we can collect Looking at the functional group perspective failure modes, we can collect
some of these into common `symptoms'. Some test cases may cause some of these into common `symptoms'. Some test cases may cause
unique failure modes at the functional group level. These can be termed unique failure modes at the functional group level. These can be termed
@ -104,7 +104,7 @@ form `test cases'.
% \item Where si,ultaneous failures are examined use overlapping contours % \item Where si,ultaneous failures are examined use overlapping contours
% \item For each region on the diagram, make a test case % \item For each region on the diagram, make a test case
\item Using the `test cases' as scenarios to examine the effects of component failures \item Using the `test cases' as scenarios to examine the effects of component failures
we determine failure~mode behaviour of the functional group. we determine the failure~mode behaviour of the functional group.
This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}. This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}.
Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined
for each test case. for each test case.
@ -260,8 +260,8 @@ We can thus apply the function $fm$ on this newly derived component thus:
$$ fm(DC) = \{ SP1, SP2, SP3 \} $$ $$ fm(DC) = \{ SP1, SP2, SP3 \} $$
Note that $g_6$ has \textbf{not disappeared from the analysis process}. Note that $g_6$ has \textbf{not disappeared from the analysis process}.
Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component. Were the designer to have overlooked this test case, it could appear as a failure mode of the derived component.
i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ would have been $ \{ SP1, SP2, g_6 \}$. i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ could have been $ \{ SP1, SP2, g_6 \}$.
Because the process can be computerised, we can easily flag symptoms that have not been Because the process can be computerised, we can easily flag symptoms that have not been
included as failure modes in a {\dc}. included as failure modes in a {\dc}.
% Aw boring ! no jokes ? % Aw boring ! no jokes ?
@ -275,7 +275,7 @@ from base level components cannot be overlooked.
{ {
An advantage of a bottom-up process is that failure modes An advantage of a bottom-up process is that failure modes
from base level components cannot be overlooked. from base level components cannot be overlooked.
The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}). The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{sec:aims}).
} }
% %
This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component

15
symptom_ex_process/topbot.tex
View File

@ -20,8 +20,8 @@ However, FMMD also provides the mathematical framework
to assist in the production of the three traditional methods of static analysis. to assist in the production of the three traditional methods of static analysis.
From the model created by the FMMD methodology, statistical, FTA and FMEA models From the model created by the FMMD methodology, statistical, FTA and FMEA models
can be derived. can be derived.
FMMD can model electrical, mechanical and software using a common notation, FMMD can model electrical, mechanical and software failures using a common notation,
and can thus model an entire electro-mechanical software controlled system. and can thus model an integrated electro-mechanical software controlled system.
\subsection{Top Down or Natural Trouble Shooting} \subsection{Top Down or Natural Trouble Shooting}
It is interesting here to look at the `natural' trouble shooting process. It is interesting here to look at the `natural' trouble shooting process.
@ -95,7 +95,7 @@ that could cause a particular mode of equipment failure.
This means that at the design stage of a product all component failure This means that at the design stage of a product all component failure
modes must be considered. The aim here is for complete failure mode coverage. modes must be considered. The aim here is for complete failure mode coverage.
This also means that we can obtain statistical estimates based on the known reliabilities This also means that we can obtain statistical estimates based on the known reliabilities
of the components. of components\cite{mil1992}.
%It also means that every component failure mode must at the very least be considered. %It also means that every component failure mode must at the very least be considered.
@ -125,7 +125,7 @@ CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
%Thinking like this is a top~down analysis approach %Thinking like this is a top~down analysis approach
%and is the way in which FTA\cite{nucfta} analyses a System %and is the way in which FTA\cite{nucfta} analyses a System
%and breaks it down. %and breaks it down.
\paragraph{Sub-systems, {\fgs} and components} \paragraph{Sub-systems, {\fgs} and components.}
A sub-system will be composed of components, which A sub-system will be composed of components, which
may themselves be sub-systems. However each `component' may themselves be sub-systems. However each `component'
will have a fault/failure behaviour and it should will have a fault/failure behaviour and it should
@ -135,8 +135,7 @@ for each `component'.
If we look at the sound system example, If we look at the sound system example,
the CD~player could fail in several distinct ways, the CD~player could fail in several distinct ways,
and this could be due to a large number of and this could have been caused by a number of component failure modes.
component failure modes.
%no matter what has happened to it or has gone wrong inside it. %no matter what has happened to it or has gone wrong inside it.
@ -152,7 +151,7 @@ These are termed `functional~groups'. For instance the circuitry that powers th
to illuminate the CD might contain a handful of components, and as such would make a good candidate to illuminate the CD might contain a handful of components, and as such would make a good candidate
to be one of the base level functional~groups. to be one of the base level functional~groups.
\paragraph{Functional group to {\dc} process outline} \paragraph{Functional group to {\dc} process outline.}
In choosing the lowest level (base component) sub-systems we would look In choosing the lowest level (base component) sub-systems we would look
for the smallest `functional~groups' of components within a system. for the smallest `functional~groups' of components within a system.
We can define a functional~group as a set of components that interact We can define a functional~group as a set of components that interact
@ -162,7 +161,7 @@ When we have analysed the fault behaviour of a functional group, we can treat it
The fault behaviour will consist of a set of `symptoms' caused by combinations The fault behaviour will consist of a set of `symptoms' caused by combinations
of its component failure modes. of its component failure modes.
We can thus make a new `component' derived from the functional~group. We can thus make a new `component' derived from the functional~group.
The symptoms are the failure modes of this new `derived component'. The symptoms of the {\fg} are the failure modes of this new `derived component'.
%We can now call our functional~group a sub-system or a derived~component. %We can now call our functional~group a sub-system or a derived~component.
%The goal here is to know how it will behave under fault conditions ! %The goal here is to know how it will behave under fault conditions !