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

JMC proof read Symptom Extraction

Browse Source
This commit is contained in:
Robin Clark 2011-01-16 12:18:37 +00:00
parent 6efe4a0e8f
commit 4ca160f7e7
4 changed files with 62 additions and 29 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

21
symptom_ex_process/algorithm.tex
View File

@ -14,19 +14,16 @@ and converts it to a derived~component/sub-system $DC$.
%of failure~modes of the sub-system.
Note that
$DC$ is a derived component at a higher level of fault analysis abstraction
than the functional~group it was derived from.
than the functional~group from which it was derived.
Thus, it can be treated
as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels}
We can assign an attribute of abstraction level $\alpha$ to
components, where $\alpha$ is a natural number, ($\alpha \in \mathbb{N}_0$).
For a base component let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$
For a base component, let the abstraction level be zero.
If we apply the symptom abstraction process $\bowtie$,
the resulting derived~component will have an $\alpha$ value
one higher that the highest $\alpha$ value of any of the components
in the functional group used to derive it.
@ -98,11 +95,11 @@ from the bottom-up.
%\clearpage
\subsection{ Determine Failure \\ Modes to examine}
\subsection{ Determine Failure Modes to Examine}
The first stage is to find the failure modes to consider for
analysis.
From the earlier definition of the function `fm':
analysis,
using the earlier definition of the function `fm'.
The function $fm$ applied to a component returns the failure modes for that component.
Thus its domain is the set of all components $\mathcal{C}$ and its range
@ -168,7 +165,7 @@ in the analysis stages.
%\clearpage
\subsection{ Determine Test Cases}
From the failure modes associated with the functional~group
From the failure modes associated with the functional~group,
we now need to determine test cases.
The test cases are collections of failure modes.
These can be formed from single failure modes or failure modes in combination.
@ -344,7 +341,7 @@ Ideally calculations or simulations
are performed to determine how the failure modes in each test case will
affect the functional~group.
%
When the all the test cases have been anaslysed
When the all the test cases have been analysed
we will have a `result' for each `test case'.
Each result will be described w.r.t. to the {\fg}, not the components failure modes
in its test case.
@ -377,7 +374,7 @@ These results are the failure modes of the functional group.
This stage collects results into `symptom' sets.
Each result from the preceding stage is examined and collected
into common symptom sets.
That is to say, each result in a symptom set, from the perspective of the functional group
That is to say, each result in a symptom set, from the perspective of the functional group,
has the same failure symptom.
Let set $\mathcal{SP}$ be the set of all symptoms,
and $\mathcal{R}$ be the set of all test case results.

25
symptom_ex_process/process.tex
View File

@ -23,14 +23,15 @@ The component failure modes in each test case
are examined with respect to their effect on the functional~group.
%
The aim of this analysis is to find out how the functional~group fails given
the test case conditions, defined in each test case.
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.
%
\paragraph{Environmental Conditions or Applied States}
Each test case must be considered in the for the case of each applied states or
environmental conditions that it may be exposed to. In this way all
Each test case must be considered for all applied/operational states and
%in the for the case of each applied states or
environmental conditions that it may be exposed to. In this way all possible
failure mode behaviour due to the test case conditions will be examined.
As part of this analysis process, records must be kept
@ -75,7 +76,7 @@ We can now consider the functional~group as a component and the symptoms as its
Note that here, because the process is bottom up, we can ensure that all failure modes
from the components in a functional~group have been handled\footnote{Software can check that all
failure modes have been included in at least one test case, and modelled individually. For Double
Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well}.
Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well.}.
Were failure~modes missed, any failure mode model could be dangerously incomplete.
It is possible here for an automated system to flag unhandled failure modes,
which solves the main failing of top~down methodologies \cite{topdownmiss}, that of not
@ -87,7 +88,7 @@ guaranteeing to model all component failure modes.
\paragraph{To analyse a base level Derived~Component/sub-system}
To sumarise:
To summarise:
\begin{itemize}
\item Choose a set of components to form a functional group.
@ -98,14 +99,14 @@ Some specific combinations of failure modes might be included. For instance wher
a very reliable part is duplicated but very critical, like the 4 engines on a 747
aircraft.}) of the failure modes to
form `test cases'.
\item If required create test cases from all valid double failure mode combinations within the {\fg}.
\item If required, create test cases from all valid double failure mode combinations within the {\fg}.
% \item Draw these as contours on a diagram
% \item Where si,ultaneous failures are examined use overlapping contours
% \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
we determine 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}.
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.
\item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the functional~group}.
\item The common~symptoms are now the fault mode behaviour of the {\fg}. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail.
@ -124,7 +125,7 @@ Each component has a set of related fault modes (i.e. ways in which it can fail
Let us define the following failure modes for each component, defining a function $fm()$
that is passed a component and returns the set of failure modes associated with it
\footnote{Base component failure modes are defined, often with
statistics and evironmental factors in a variety of sources. \cite{mil1991}
statistics and environmental factors in a variety of sources. \cite{mil1991}
}.
@ -298,7 +299,7 @@ $$
Given by
$ \bowtie ( FG ) = DC $
as per the example in preceeding section \ref{theoreticalsx}.
as per the example in precedeing section \ref{theoreticalsx}.
\paragraph{Extending $\bowtie$ to {\dcs}}
@ -320,7 +321,7 @@ to the {\fg} comprised of derived components
because we can obtain a failure mode set,
(the failure mode set we have named $DCFM$).
Thus we can now move up another abstaction level by applying
Thus we can now move up another abstraction level by applying
symptom abstraction/extraction to the functional group
$FG_{derived}$ shown in equation \ref{eqn:fgderived}.
@ -356,10 +357,10 @@ to keep track of the abstraction level of a {\dc}.
%%\end{equation}
In other words by analysing a functional group containing derived components
In other words by analysing a functional group containing derived components,
we have a new derived component as our result.
This naturally
builds a bottom-up failure mode model,
builds a bottom-up failure mode model and
with each iteration the model becomes more abstract will eventually reach
the SYSTEM level.

37
symptom_ex_process/sys_abs.tex
View File

@ -4,6 +4,41 @@
%%
%%
%%
%
% ________________,------.
% /_|_____||____|__| | | ___________
% `,---,-' __,---' `---.__
% / / __,--'---._______________.---'
% ____/ /--'___________.-'
% `-./___/______________/
% `---------'
%
% .-. .-.
% ( ) ___________ ( )
% `-' __,----' \v/ `----.__ `-'
% \\'----._______________.----'//
% \\________.-'/|\`-.________//
% `=====<___ @ __>======'
% `-----'
%
% ________________,------.
% (_)_____||____|__| | |
% `,---,-' _.-----._
% /___/ ,-' | `-.
% / `-._ ,' | `.
% | `-._ / `. | ,' \
% / `/ `. | ,'_ \
% |__ | `. .-. ,' /__ |
% |__|--O------<|-------- ( ) --|__>--|
% | | ,' `-' `. \_ |
% \ _,\ ,' | `. /
% | _,-' \ ,' | `. /
% \___\,-' `. | ,'
% \ \ `-._ | _.-'
% ________________,`---`-. `-----'
% (_)_____||____|__| | |
%
\section{The Symptom Extraction Process}
% TO DO: separate these two:
@ -31,7 +66,7 @@ The goal of the process is to produce a set of failure modes from the perspectiv
\paragraph{Environmental Conditions or Applied States}
Each test case must be considered in the light of any applied states or
Each test case must be considered in the light of any operational states or
environmental conditions that it may be exposed to.
\paragraph{Electronics}

8
symptom_ex_process/topbot.tex
View File

@ -23,7 +23,7 @@ can be derived.
FMMD can model electrical, mechanical and software using a common notation,
and can thus model an entire 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.
Fault finding is instinctively performed from the top-down.
A faulty piece of equipment is examined and will have a
@ -87,7 +87,7 @@ and now we may treat the functional group as a component, as it has a known set
%
By reusing the `components' derived from functional~groups an entire
hierarichal failure mode model of the system can be built.
That is to say, using derived components in higher level functional groups
That is to say, using derived components in higher level functional groups,
a hierarchy is naturally formed.
%
By working from the bottom up, we can trace all possible sources
@ -152,7 +152,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 be one of the base level functional~groups.
\paragraph{{\fg} to {\dc} process outline}
\paragraph{Functional group to {\dc} process outline}
In choosing the lowest level (base component) sub-systems we would look
for the smallest `functional~groups' of components within a system.
We can define a functional~group as a set of components that interact
@ -192,7 +192,7 @@ System & A product designed to \\
& work as a coherent entity \\ \hline
Sub-system & A part of a system, \\
-or- derived component & sub-systems may contain sub-systems. \\
& derived~components may by derived \\
& derived~components may be derived \\
& from derived components \\
& Constraint: This object must have a defined set of failure~modes \\ \hline
Failure mode & A way in which a system, \\