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

red penned and edited

Browse Source
This commit is contained in:
Robin Clark 2012-12-31 16:04:22 +00:00
parent 6c3469c27b
commit 2c57afb5b4
1 changed files with 70 additions and 32 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

102
submission_thesis/appendixes/algorithmic.tex
View File

@ -1,11 +1,22 @@
\chapter{Algorithmic Description of Symptom Abstraction}
\chapter{Algorithmic Description of FMMD}
%\label{sec:symptom_abstraction}
\label{sec:algorithmfmmd}
This section uses algorithms and set theory to describe the process for
analysing a {\fg} and determining from it a {\dc}.
It begins with an overview of the FMMD process, and then contrasts and compares it
to diagnostic analysis (fault finding).
%
\paragraph{Symptom Abstraction in brief}
\section{FMMD as a process.}
In FMMD we take a group of components with a functional purpose, apply
FMEA, and then determine how the {\fg} can fail.
We determine the common symptoms of failure of the {\fg}, and then
create a new {\dc} which has, as its failure modes, the symptoms we determined.
\paragraph{FMMD and failure mode models.}
In essence, we take a {\fg} (a collection of components),
and apply FMEA analysis locally on this {\fg}.
%
@ -18,7 +29,7 @@ we are able to collect common symptoms of failure for the {\fg}.
%
With the collected common symptoms, we can treat the {\fg}
as a component in its own right.
This new component, is derived from the {\fg}.
This new component being derived from the {\fg}.
In the field of safety engineering this derived component corresponds 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.
%
@ -34,7 +45,7 @@ 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.
Once a hierarchy is in place, it can be converted into a generic failure mode model.
\fmmdgloss
%
From the fault data model, automatic generation
@ -51,7 +62,13 @@ The symptom extraction or abstraction process, is the key process in creating an
\subsection{Fault Finding and Failure Mode Analysis}
\subsection{Diagnostic analysis and Failure Mode Analysis}
Fault finding is a closely related discipline to failure mode analysis.
In diagnostic analysis, we generally start with a high level --- or system ---failure type.
We trace this from the top, de-composing the systems until we come to
a component or sub-system that has caused the failure.
While there are similarities between diagnostic failure mode tracing and static failure mode analysis
it is important to discuss the differences between them.
%
%\subsection{Static Analysis}
%
@ -76,7 +93,7 @@ The symptom extraction or abstraction process, is the key process in creating an
%and can thus model an integrated electro-mechanical software controlled system.
%
\subsection{Top Down or Natural Trouble Shooting}
It is interesting here to look at the `natural' trouble shooting process.
We firstly 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
symptom or specific fault.
@ -92,7 +109,7 @@ and checks will be made, and finally a component or a low level sub-system
will be found to be faulty.
A natural fault finding process is thus top~down.
Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}.
Fault tree analysis is a top down static failure mode analysis technique~\cite{nucfta,nasafta}.
%%
%% to fool the graphics insertion to make it compatible
%% with thesis and papaer level directories.
@ -145,8 +162,8 @@ a hierarchy is naturally formed.
By working from the bottom up, we can trace all possible sources
that could cause a particular mode of equipment 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.
This also means that we can obtain statistical estimates based on the known reliabilities
modes must be considered. A benefit of FMMD is complete failure mode coverage.
This also means that it is possible to obtain statistical estimates based on the known reliabilities
of components~\cite{mil1991}.
%It also means that every component failure mode must at the very least be considered.
@ -206,11 +223,11 @@ of components~\cite{mil1991}.
\nocite{safeware}
\section{Overview of Symptom Extraction Process}
\section{Overview of the FMMD analysis Process}
% TO DO: separate these two:
\paragraph{Symptom Extraction Objective.}
\paragraph{FMMD analysis Objective.}
The objective of `symptom abstraction' is to analyse the functional~group and find
how it can fail
when specified components within it fail.
@ -242,13 +259,13 @@ a set of failure mode symptoms. The designer can now treat this piece of circuit
Each test case must be considered for all applied/operational states and
%in the for the case of each applied states or
environmental conditions to which it may be exposed. In this way, all possible
failure mode behaviour due to the test case conditions will be examined.
failure mode behaviour due to all the conditions that can be applied to a test case will be examined.
As part of this analysis process, records must be kept
detailing each test case result along with its resultant
{\fg} failure mode.
This data will be kept in the model and can be used to
examine environmentally sourced common mode failure scenarios.
If this data is kept in the model and could be used to
automatically examine the effects of environmentally sourced common mode failure scenarios.
%%- A {\fg} may, in the case of an electronic circuit have
@ -267,30 +284,44 @@ When all `test~cases' have been analysed, a second phase can be actioned. % appl
%
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.
%Single component failures (or combinations) within the functional~group may cause unique symptoms.
However, many failures, when looked at from the perspective of the functional group, will have the same symptoms.
%However, m
Many failures, when looked at from the perspective of the functional group, will have the same symptoms.
These can be collected as `common symptoms'.
%
To go back to the CD~player example, a failed
output stage, and a failed internal audio amplifier,
will both cause the same failure; $no\_sound$ !
will both cause the same failure symptom; $no\_sound$ !
\paragraph{Collection of Symptoms.}
Looking at the functional group perspective failure modes, we can collect
some of these into common `symptoms'. Some test cases may cause
%Looking at the
examining failure from the
functional group perspective failure modes, we collect
some of these into common `symptoms' where possible.
%
Some test cases may cause
unique failure modes at the functional group level. These can be termed
lone symptoms.
%
The common symptoms of failure and lone~symptoms are identified and collected.
We can now consider the functional~group as a component and the symptoms as its failure modes.
Note that here, because the process is bottom up, we can ensure that all failure modes
%
We can now create a new component and consider the symptoms as its failure modes.
%
We call this new component a `{\dc}'.
%
%Note that here, b
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.}.
%
Were any failure~modes missed, the failure mode model could be dangerously incomplete.
Were any failure~modes missed, the failure mode model could be %dangerously
incomplete.
%
It is possible here for an automated system to flag un-handled failure modes,
which solves the main failing of top~down methodologies
%\cite{topdownmiss},
@ -815,15 +846,16 @@ cases can have no pairs of failure modes sourced from the same component.
\label{sec:completetest}
This function also ensure completeness in the model.
It ensures that for all failure modes in the {\fg} are considered in a test~case.
This function also ensures completeness in the model.
It ensures that %for
all failure modes in the {\fg} are considered in a test~case.
%
\ifthenelse {\boolean{paper}}
{
%% perhaps ref a paper here XXXXX
}
{
This is discussed in chapter \ref{sec:unitarystate}.
Components with a unitary state property are discussed in chapter \ref{sec:unitarystate}.
}
%%
%% Algorithm 2
@ -970,19 +1002,21 @@ Algorithm \ref{alg33} has built the set $R$, the sub-system/functional group res
The analysis is primarily a human activity.
%
Each test case is examined in detail.
%Each test case is examined in detail.
%
%
Calculations or simulations
are performed to determine how the failure modes in each test case will
affect the functional~group.
Ideally field and formal physical testing data should be used in addition
Ideally field data and/or formal physical testing should be used in addition static failure mode reasoning
where possible.
%
When the all the test cases have been analysed
we will have a `result' for each `test case'.
Each result will be described {\wrt} to the {\fg}, not the components failure modes
in its test case.
%
Each result will be described from the perspective of %{\wrt} to
the {\fg}, not the components failure modes.
%in its test case.
%
%In the case of a simple
%electronic circuit, we could calculate the effect on voltages
@ -1144,7 +1178,7 @@ to form functional~groups at higher levels of failure~mode~abstraction.
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
\subsection{Hierarchical Simplification}
Because symptom abstraction collects fault modes, the number of faults to handle decreases
Because symptom abstraction collects aggregates fault modes, the number of faults to handle should decrease
as the hierarchy progresses upwards.
%This is seen by casual observation of real life Systems. NEED A GOOD REF HERE
At the highest levels the number of faults
@ -1155,13 +1189,17 @@ $$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT
\normalsize
The number of causes for any of these faults is very large.
It does not matter to the user, which combination of component failure~modes caused the fault.
But as the hierarchy goes up in abstraction level, the number of failure modes goes down for each level.
But as the hierarchy goes up in abstraction level, the number of failure modes goes down for each level:
as is found in practise in real world systems.
\subsection{Traceable Fault Modes}
Because the fault modes are determined from the bottom-up, the causes
for all high level faults naturally form trees.
These trees can be traversed to produce
That is to say from the bottom-up causes become symptoms which in the next level become causes as we traverse up the tree.
This is demonstrated in the examples chapter~\ref{sec:chap5} where DAGS are drawn linking failure mode causes and symptoms
in FMMD analysis hierarchies.
These trees can be also traversed to produce
minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by
analysing the statistical likelihood of the component failures,
the Mean Time to Failure (MTTF) and SIL\cite{en61508} levels can be automatically calculated.