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

Merge branch 'master' of dev:/home/robin/git/thesis

Browse Source 
Conflicts:
	lifecycle_modelling/paper.tex
This commit is contained in:
Robin Clark 2010-11-04 09:12:19 +00:00
commit b451493b94
14 changed files with 450 additions and 69 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

20
common_mode/Makefile Normal file
View File

@ -0,0 +1,20 @@
#
paper: paper.tex common_mode_paper.tex
#latex paper.tex
#dvipdf paper pdflatex cannot use eps ffs
pdflatex paper.tex
mv paper.pdf common_mode.pdf
okular common_mode.pdf
# Remove the need for referncing graphics in subdirectories
#
common_mode_paper.tex: common_mode.tex paper.tex
cat common_mode.tex | sed 's/common_mode\///' > common_mode_paper.tex
bib:
bibtex paper

98
common_mode/common_mode.tex Normal file
View File

@ -0,0 +1,98 @@
\ifthenelse {\boolean{paper}}
{
\abstract{
This paper describes how the Failure Mode Modular De-composition (FMMD) methodology
can be applied to the problems of common mode failure
analysis.
%
Common mode failures are often difficult to
determine in embedded real time systems.
%
Environmental effects can lead to component failure
modes, that can occur in separate sub-systems
in a system, but interact to create unexpected fault.
% WHAT IS DID
The FMMD methodology can model and warn for two types of common mode failures.
Failures caused by separate sub-systems relying on
a common component, and environmental effects that can induce failure
modes in components in separate sub-systems.
% WHAT I FOUND
From the FMMD data model it is possible to link the environmental effects
and ensure determine the weak points in a design, where the failure modes may interact.
For the component dependency case, the dependent component
can be automatically highlighted by traversing the data model.
% WHY YOU WOULD WANT TO READ IT
This feature of FMMD proides another tool in the safety engineers
repotiore, one that can shake out difficult to find common mode failure
effects.
}
}
{
\paragraph{Chapter overview}
This chapter describes how the % Failure Mode Modular De-composition (FMMD)
FMMD methodology
can be applied to the problems of common mode failure
analysis.
%
Common mode failures are often difficult to
determine in embedded real time systems.
%
Environmental effects can lead to component failure
modes, that can occur in separate sub-systems
in a system, but interact to create unexpected fault.
% WHAT IS DID
The FMMD methodology can model and warn for two types of common mode failures.
Failures caused by separate sub-systems relying on
a common component, and environmental effects that can induce failure
modes in components in separate sub-systems.
% WHAT I FOUND
From the FMMD data model it is possible to link the environmental effects
and ensure determine the weak points in a design, where the failure modes may interact.
For the component dependency case, the dependent component
can be automatically highlighted by traversing the data model.
% WHY YOU WOULD WANT TO READ IT
This feature of FMMD proides another tool in the safety engineers
repotiore, one that can shake out difficult to find common mode failure
effects.
}
\section{Introduction}
\ifthenelse {\boolean{paper}}
{
paper
}
{
chapter
}
Outline the fmmd process.
Show modules with common dependencies (like on a power supply, a powersupply could have a fault
like nopisy output)
Trace a theoretical example and show how FMMD detects this (common dependency - like two
{\dc}s being depemdent on the same failure mode.
Then show an environmental effect, such as temperature and how
it can induce faults in sepatate modulkes that
would not be obviously related.
Trace a theoretical example and show how FMMD detects this
i.e. the environmental factor affecting both systems and causing a problem.
what about the third way it can be affected.
Like a chain of relays...... all could get welded .... think about that one.....

31
common_mode/paper.tex Normal file
View File

@ -0,0 +1,31 @@
\documentclass[a4paper,10pt]{article}
\usepackage{graphicx}
\usepackage{fancyhdr}
\usepackage{tikz}
\usepackage{amsfonts,amsmath,amsthm}
\input{../style}
\usepackage{ifthen}
\newboolean{paper}
\setboolean{paper}{true} % boolvar=true or false
%\newtheorem{definition}{Definition:}
\begin{document}
\pagestyle{fancy}
%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}}
%\innerfoot{{\small\bf R.P. Clark } }
% numbers at outer edges
\pagenumbering{arabic} % Arabic page numbers hereafter
\author{R.P.Clark}
\title{Modelling and Uncovering Common Mode Failures using FMMD}
\maketitle
\input{common_mode_paper}
\bibliographystyle{plain}
\bibliography{../vmgbibliography,../mybib}
\today
\end{document}

6
component_failure_modes_definition/component_failure_modes_definition.tex
View File

@ -664,6 +664,12 @@ such as Bayes theorem \cite{probstat}.
%%- the other parts were just fragments to illustrate points
%%-
%%-
\section{Complete UML Diagram}
\section{From UML Model to Data Model}
\subsection{Directed Acyclic Graph}
\subsection{Traversing the datamodel}
\subsubsection{Common mode failure detection}
\subsubsection{Common dependency detection}
\vspace{40pt}

110
fmmd_concept/fmmd_concept.tex
View File

@ -14,7 +14,7 @@ incremental and rigorous approach.
%% What I have done
%%
The Four main static failure mode analysis methodologies were examined and
in in the context of newer European safety standards assessed.
in the context of newer European safety standards assessed.
Some of the defeciencies in these methodologies lead to
a wish list for a more ideal methodology.
@ -27,7 +27,7 @@ methodology is developed. The has been named Failure Mode Modular De-Composition
%% Sell it
%%
In addition to addressing the traditional weaknesses of
Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Faliue Mode Effects Criticallity Analysis (FMECA)
Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Failure Mode Effects Criticallity Analysis (FMECA)
and Failure Mode Effects and Diagnostic Analysis (FMEDA), FMMD provides the means to model multiple failure mode scenarios
as specified in newer European Safety Standards \cite{en298}.
The proposed methodology is bottom-up and
@ -145,14 +145,14 @@ are held in a computer program, we can determine if the model is complete
\subsection{General Comments on bottom-up and top down approaches}
\paragraph{A general Problem with top-down}
\paragraph{A general defeciency in top-down systems analysis}
With a top down approach the investigator has to determine
a set of undesireable outcomes or accidents.
a set of undesirable outcomes or accidents.
As most accidents are unexpected and the causes unforseen \cite{safeware}
it is fair to say that a top down approach is not guaranteed to
predict all possible undesirable outcomes.
It also can miss known component failure modes, by
simple not de-composing down to that level of detail.
simply not de-composing down to that level of detail.
\paragraph{A general problem with bottom-up}
With the bottom up techniques we have all the known component failure modes
@ -165,22 +165,22 @@ we cannot consider them all and human judgement is used to
decide which interactions are important.
Let N be the number of components in our system, and K be the average number of component failure modes
(ways in which the component can fail). The total number of base component failure modes
is $N \times K$. To even examine the affect that one failure mode has on all the other components
(ways in which the component can fail). The total number of base comp failure modes
is $N \times K$. To examine the affect that one failure mode has on all the other components
will be $(N-1) \times N \times K$, in effect a set cross product.
Complicate this further with applied states or environmental conditions
and another order of cross product of complexity is added.
We may have a peice of self checking circuity for instance that
We may have a piece of self checking circuitry for instance that
has two states, normal and testing mode commanded by a logic line.
Or we may have a mechanical device that has a different
failure mode behaviour for say, differnet ambient pressures or temperatures.
failure mode behaviour for say, different ambient pressures or temperatures.
If $E$ is the number of applied states or environmental conditions to consider
in a system, the job of the bottom-up analyst is complicated by a cross product factor again
$(N-1) \times N \times K \times E$.
If we put some typical very small embedded system numbersi\footnote{these figures would
If we put some typical very small embedded system numbers\footnote{these figures would
be typical of a very simple temperature controller, with a micro-controller sensor and heater circuit} into this, say $N=100$, $K=2.5$ and $E=10$
we have $99 \times 100 \times 2.5 \times 10 = 247500 $.
To look in detail at a quarter of a million test cases is obviously impractical.
@ -188,7 +188,7 @@ To look in detail at a quarter of a million test cases is obviously impractical.
If we were to consider multiple simultaneous failure modes
we have yet another complication cross product.
For instance for looking at double simultaneous failure modes
For instance for looking at double simultaneous failure modes,
the equation reads $(N-2) \times (N-1) \times N \times K \times E$.
The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes and link them
@ -198,8 +198,8 @@ component failure mode to the SYSTEM level.
\paragraph{Ideal Static failure mode methodology}
An ideal Static failure mode methodology would build a failure mode model
\paragraph{Ideal static failure mode methodology}
An ideal static failure mode methodology would build a failure mode model
from which the traditional four models could be derived.
It would address the short-comings in the other methodologies, and
would have a user friendly interface, with a visual (rather than mathematical/formal) syntax with icons
@ -217,7 +217,7 @@ of missing component failure modes \cite{faa}[Ch.9].
%, or modelling at
%a too high level of failure mode abstraction.
FTA was invented for use on the minuteman nuclear defence missile
systems in the early 1960's and was not designed as a rigorous
systems in the early 1960s and was not designed as a rigorous
fault/failure mode methodology. It is more like a structure to
be applied when discussing the safety of a system, with a top down hierarchical
notation, that guides the analysis. This methodology was designed for
@ -244,7 +244,7 @@ The investigation will typically point to a particular failure
of a component.
The methodology is now applied to find the significance of the failure.
Its is based on a simple equation where $S$ ranks the severity (or cost \cite{fmea}) of the identified SYSTEM failure,
$O$ its occurrance, and $D$ giving the failures detectability. Muliplying these
$O$ its occurance, and $D$ giving the failures detectability. Muliplying these
together,
gives a risk probability number (RPN), given by $RPN = S \times O \times D$.
This gives in effect
@ -286,7 +286,7 @@ The results, as with FMEA are an $RPN$ number determining the significance of th
%%-WIKI- while various forms of FMEA predominate in other industries.
\subsubsection{ FMEA weaknesses }
\subsubsection{ FMECA weaknesses }
\begin{itemize}
\item Possibility to miss the effects of failure modes at SYSTEM level.
\item Possibility to miss environmental affects.
@ -314,7 +314,7 @@ The component may be mitigated by a vatriety of factors
\item Coverage of self checking
\end{itemize}
Ultimately this tequnique calculates a risk factor for each component.
Ultimately this technique calculates a risk factor for each component.
The risk factors of all the components are summed and
give a value for the `safety level' for the equipment in a given environment.
@ -327,32 +327,44 @@ give a value for the `safety level' for the equipment in a given environment.
%%-• The design strength (de-rating, safety factors) and
%%-• The operational profile (environmental stress factors).
This uses MTFF and other statisical models to determine the probability of
failures occurring. A component failure mode, given its MTTF
This uses MTFF and other statistical models to determine the probability of
failures occurring.
%
A component failure mode, given its MTTF
the probability of detecting the fault and its safety relevant validation time $\tau$,
contributes a simple risk factor that is summed
in to give a final risk result. Thus a statistical
in to give a final risk result.
%
Thus a statistical
model can be implemented on a spreadsheet, where each component
has a calculated risk, a fault detection time (if any), an estimated risk importance
and other factors such as de-rating and environmental stress.
This can be calculated, with one component failure mode per row, on a spreadsheet
and these are all summed to give the final assessment figure.
\paragraph{Two statistical perspectives}
The Statistical Analysis method is used from two perspectives,
\subsubsection{Two statistical perspectives}
he Statistical Analysis method is used from two perspectives,
Probability of Failure on Demand (PFD), and Probability of Failure
in continuous Operation, Failure in Time (FIT) and measured in failures per billion ($10^9$) hours of operation.
in continuous Operation, Failure in Time (FIT).
\paragraph{Failure in Time (FIT)}.
Continuous operation is measured in failures per billion ($10^9$) hours of operation.
For a continuously running nuclear powerstation
we would be interested in its operational FIT values.
\paragraph{Probability of Failure on Demand (PFD)}.
For instance with the anti-lock system on a automobile braking
system, we would be interested in PFD.
For a continuously running nuclear powerstation
we would be interested in its 24/7 operation FIT values.
That is to say the ratio of it failing
to succeeding on demand.
\subsubsection{FMEDA and determinability prediction accuracy}.
This suffers from the same problems of
lack of determinability prediction accuracy, as FMEA above.
%
We have to decide how particular components failing will impact on the SYSTEM or top level.
This involves a `leap of faith'. For instance, a resistor failing in a sensor circuit
may be part of a critical monitioring function.
may be part of a critical monitoring function.
The analyst is now put in a position
where he must assign a critical failure possibility to it.
%
@ -361,10 +373,10 @@ of how that resistor would/could affect that circuit, but because the circuitry
it is part of critical section it will be linked to a critical system level fault.
%
A $\beta$ factor, the hueristically defined probability
of the failure causign the system fault may be applied.
of the failure causing the system fault may be applied.
%
But because there is no detailed analysis of the failure mode behaviour
of the component, traceable to the SYSTEM level, it becomnes more
of the component, traceable to the SYSTEM level, it becomes more
guess work than science.
With FMEDA, there is no rigorous cause and effect analysis for the failure modes. Unintended side
effects that lead to failure can be missed.
@ -401,6 +413,10 @@ for its results.
\item It should be capable of producing reliability and danger evaluation statistics.
\item It should be easy to use, Ideally using a graphical syntax (as oppossed to a formal mathematical one).
\item From the top down, the failure mode model should follow a logical de-composition of the functionality
for its results.
\item It should be capable of producing reliability and danger evaluation statistics.
\item It should be easy to use, ideally using a graphical syntax (as oppossed to a formal mathematical one).
\item From the top down, the failure mode model should follow a logical de-composition of the functionality
to smaller and smaller functional modules \cite{maikowski}.
\item Multiple failure modes may be modelled from the base component level up.
\end{itemize}
@ -408,7 +424,7 @@ to smaller and smaller functional modules \cite{maikowski}.
\section{Design of a new static failure mode based methodology}
\paragraph{New methodology Must be bottom-up}
\paragraph{New methodology must be bottom-up}
In order to ensure that all component failure modes have been covered
the methodology will have to work from the bottom-up
and start with the component failure modes.
@ -418,7 +434,7 @@ The traditional fault finding, or natural fault finding
is to work from the top down.
%
On encountering a
fault, the symptom is first know at the top or
fault, the symptom is first observed at the top or
SYSTEM level. By de-composing the functionality of the faulty system and testing
we can further de-compose the system until we find the
faulty base level component.
@ -428,10 +444,10 @@ Simpler and simpler functional blocks are discovered as we delve
further into the way the system works and is built.
\paragraph{Design Decision: Methodology must be bottom-up.}
In oder to ensure that all component failure modes are handled,
In order to ensure that all component failure modes are handled,
this methodology must start at the bottom, with base component failure modes.
In this way automated checking can be applied to all component failure modes
to ensure none have been inadvertantly excluded from the process.
to ensure none have been inadvertently excluded from the process.
\paragraph{Need for a `bottom-up' system de-composition}
There is an apparent conflict here. The natural way to
@ -446,7 +462,7 @@ and then taking those to form higher level
The philosophy of top down de-compositon is very similar.
Top down de-compositon applies functional
de-composition, because it seeks to break the system down
into manageable and separatetly testable entities.
into manageable and separately testable entities.
A second justification for this is that the design process for a product requires both top down and bottom-up
thinking.
@ -459,17 +475,21 @@ The base components will typically have several failure modes each.
Given a typical embedded system may have hundreds of components
This means that we have to tie base component failure modes
to SYSTEM level errors. This is the `possibility to miss failure mode effects
at SYSTEM level' critism of the FTA, FMEDA and FMECA methodologies.
at SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies.
\paragraph{Design Decision: Methodolgy must reduce and collate errors at each functional group stage.}
SYSTEMS typically have far fewer failure modes then the sum of their component failure modes.
SYSTEMS typically have far fewer failure modes than the sum of their component failure modes.
SYSTEM level failures may be caused by a variety of component failure modes.
A SYSTEM level failure mode is an abstracted failure mode, in that
it is a symptom of some lower level failure or failures.
% ABSTRACTION
For instance a failed resistor in a sensor at a base component level is a specific
failure mode. For example it could be called `RESISTOR 1 OPEN'.
Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract.
failure mode.
%
For example it could be called `RESISTOR 1 OPEN'.
Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract
or in other words describe the effect more generally.
%
We might call it `READING~HIGH' perhaps. At a higher level still
this may be called `SENSOR CHANNEL 1' fault.
At a system level it may simply be a `SENSOR FAILURE'.
@ -485,7 +505,7 @@ of failure modes as the abstraction level reaches the SYSTEM level.
The next problem is how to we build a failure mode model
that converges to a finite set of SYSTEM level failure modes.
%
It would be better would be to analyse the failure mode behaviour of each
It would be better to analyse the failure mode behaviour of each
functional group, and determine the ways in which it, rather than its
components, can fail.
%
@ -502,7 +522,7 @@ The number of symptoms of failure should be equal to or
less than the number of component failure modes, simply because
often there are several potential causes of failure symptoms.
%
When we have the the symptoms, we can start thinking of the {\fg} as a component in its own right.
When we have the symptoms, we can start thinking of the {\fg} as a component in its own right.
%with a simplified and reduced set of failure symptoms.
%
We can now create a new {\dc}, where its failure modes
@ -534,7 +554,7 @@ are the same failure w.r.t. the {\fg}.
%
We can now treat the {\fg} as a component, and call it a {\dc}, in other words, a sub-system with a known set of failure modes.
%
We can now create a new{\dc} and assign it these common symptoms
We can now create a new {\dc} and assign it these common symptoms
as its failure modes.
%
This {\dc} can be used to build higher level
@ -544,7 +564,7 @@ an entire system. It can be considered complete when
all failure modes from all components are handled
and connectable to a SYSTEM level failure mode.
\paragraph{Directed Acyclic Graph}. This will naturally form a DAG
\paragraph{Directed Acyclic Graph.} This will naturally form a DAG
meaning that for all SYSTEM failure modes, we will be able to trace
back through the DAG to possible component failure mode causes.
If statistical models exist for the component failure modes
@ -573,7 +593,7 @@ We can then treat the {\fg} as a `black box' or component in its own right.
We can now look at how the {\fg} can fail.
%
Many of the component failure modes will
cause the same failure symptoms in the {fg} failure behaviour.
cause the same failure symptoms in the {\fg} failure behaviour.
We can collect these failures as common symptoms.
%
When we have our set of symptoms, we can now create
@ -601,8 +621,8 @@ This ensures that all component failure modes are handled.
\subsubsection{ It should be easy to integrate mechanical, electronic and software models.}
Because component failure modes are considered, we have a generic enitity to model.
We can describe a mecanical, electrical or software component in terms of its failure modes.
Because component failure modes are considered, we have a generic entity to model.
We can describe a mechanical, electrical or software component in terms of its failure modes.
%
Because of this
we can model and analyse integrated electro mechanical systems, controlled by computers,
@ -666,7 +686,7 @@ chosing {\fg}s and working bottom-up this hierarchical trait will occur as a nat
\section{Conclusion}
This paper provides the backgroud for the need for a new methodology for
This paper provides the background for the need for a new methodology for
static analysis that can span the mechanical electrical and software domains
using a common notation.
\vspace{60pt}

3
lifecycle_modelling/Makefile
View File

@ -1,6 +1,7 @@
#
#
#
paper: paper.tex lifecycle_modelling_paper.tex
#latex paper.tex

13
lifecycle_modelling/lifecycle_modelling.tex
View File

@ -27,6 +27,7 @@ paper
chapter
}
\section{discovering a `new' failure mode in a component}
Give general idea of how a new failure mode can be integrated into the model.
@ -36,3 +37,15 @@ How it will generally be limited to small sections of th FMMD tree.
Give specific example, pretend a new failure mode is discovered in a SCHOTTKY diode.
Often an electronic component will have a new failure mode `discovered'
I am using as an example a diode which has an exponential relationship
with temperature and reverse leakage current. This is
a failure mode that would not be initially considered in a design.
But when combined with high value resistors could give incorrect voltage readings in some circuits.
I how the FMMD model can have this new failure mode added and what
impact it has on the FMMD data model.
\section{Discovering New Failure Mode behaviour ina {\dc}}
\section{New or additional evironmental Conditions}

7
lifecycle_modelling/paper.tex
View File

@ -1,4 +1,5 @@
\documentclass[a4paper,10pt]{article}
\usepackage{graphicx}
\usepackage{fancyhdr}
@ -20,9 +21,15 @@
% numbers at outer edges
\pagenumbering{arabic} % Arabic page numbers hereafter
\author{R.P.Clark}
<<<<<<< HEAD
\title{FMMD Lifecycle Modelling}
\maketitle
\input{lifecycle_modelling}
=======
\title{Product Lifecycle Modelling with FMMD}
\maketitle
\input{lifecycle_modelling_paper}
>>>>>>> 53352f41d87e0db41a23770a5da443a9345b982e
\bibliographystyle{plain}
\bibliography{../vmgbibliography,../mybib}

6
symptom_ex_process/introduction.tex
View File

@ -30,7 +30,9 @@ 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}.
automatically \footnote{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.
This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy.
We can term this stage in FMMD analysis as the `symptom extraction' process.
The symptom extraction or abstraction process, is the key process in creating an FMMD hierarchy.
}

78
symptom_ex_process/process.tex
View File

@ -1,4 +1,4 @@
\nocite{safeware}
\section{Overview of Symptom Extraction Process}
% TO DO: separate these two:
@ -33,6 +33,13 @@ 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
failure mode behaviour due to the test case conditions 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.
%%- A {\fg} may, in the case of an electronic circuit have
%%- applied states. For instance test modes, shutdown or lockout modes etc.
%%- which are inputs to the circuit.
@ -109,7 +116,6 @@ for each test case.
\pagebreak[1]
\section{A theoretical `Derived Component' example}
Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$.
$$ FG = \{ C_1 , C_2 , C_3 \} $$
@ -178,6 +184,7 @@ This can be seen as all the failure modes that can affect the failure mode group
\subsection{Analysis of the functional group failure modes}
\label{theoreticalsx}
For this example we shall consider single failure modes.
%For each of the failure modes from $fm(FG)$ we shall
%create a test case ($g_i$). Next each test case is examined/analysed
@ -270,6 +277,11 @@ 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}).
}
%
This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component
with known failure modes
(although at a higher level of abstraction).
This process can be repeated using {\dcs} to build a
hierarchical fault~mode model.
The newly derived component $DC$ is available for use to form higher level functional groups, and we can thus
consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
@ -277,13 +289,17 @@ consider DC as being in the set of components i.e. $DC \in \mathcal{C}$
\subsection{Defining the analysis process \\ as a function}
Where $\mathcal{F}$ is the set of all sets of failure modes, and $\mathcal{DC}$
Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$
is the set of all derived components, we can define the symptom abstraction process thus:
$$
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent
\bowtie : \mathcal{F} \rightarrow \mathcal{DC}
\bowtie : \mathcal{FG} \rightarrow \mathcal{DC} .
$$
Given by
$ \bowtie ( FG ) = DC $
as per the example in preceeding section \ref{theoreticalsx}.
\paragraph{Extending $\bowtie$ to {\dcs}}
It is useful to further define the $\bowtie$ function, to
@ -293,21 +309,38 @@ This generalises the function $\bowtie$ and allows us to build
hierarchical failure mode models.
Where a {\fg} is composed of derived components, for sake of example
where $DC_1, DC_2, DC_3 $ are {\dc}s and $DCFM$ is a set of failure modes thus
$FG = \{ DC_1, DC_2, DC_3 \}$ and $DCFM = FM(FG)$.
where $DC_1, DC_2, DC_3 $ are {\dc}s we could collect these into a {\fg} thus
$FG_{derived} = \{ DC_1, DC_2, DC_3 \}$.
$DCFM$ is a set of failure modes from the new {\fg} $FG_{derived},$
$DCFM = fm(FG_{derived})$.
We can apply the symptom abstraction process $\bowtie$
to the failure mode set $DCFM$.
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
symptom abstraction/extraction to the functional group
$FG_{derived}$ shown in equation \ref{eqn:fgderived}.
\begin{equation}
\label{eqn:fgderived}
\bowtie ( FG_{derived} ) = DC_{derived}
\end{equation}
The case
where a {\fg} has been created from {\dcs}
using function `$\bowtie$' leads us to
{\dc}s at a higher level of fault abstraction.
{\dc}s at a higher level of failure mode abstraction.
A notation will be described in the next section
to keep track of the abstraction level of a {\dc}.
$$
%%$$
%\bowtie : SubSystemComponentFaultModes \rightarrow DerivedComponent
\bowtie : DCFM \rightarrow DC
$$
%%\bowtie : FG_{derived} \rightarrow DC
%%$$
%
%\begin{equation}
% \bowtie(FG_{cfm}) = DC
@ -315,14 +348,21 @@ $$
%
%or applying the function $fm$ to obtain the $FG_{cfm}$ set
%
To put this in context, where FG is a functional group, sourced from base or derived components,
we may state the process of
analysing the failure modes in the {\fg} and returning a {\dc} thus:
\begin{equation}
\bowtie(fm(FG)) = DC
\end{equation}
%%To put this in context, where FG is a functional group, sourced from base or derived components,
%%we may state the process of
%%analysing the failure modes in the {\fg} and returning a {\dc} thus:
%%\begin{equation}
%% \bowtie((FG)) = DC
%%\end{equation}
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,
with each iteration the model becomes more abstract will eventually reach
the SYSTEM level.
%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour.
%The derivation of $SS_{fm}$ is represented graphically using the `$\bowtie$' symbol, as in figure \ref{fig:gensubsys4}
@ -334,10 +374,6 @@ analysing the failure modes in the {\fg} and returning a {\dc} thus:
% \caption{Deriving a new diagram}
This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component (although at a higher level of abstraction)
with known failure modes.
This process can be repeated using {\dcs} to build a
hierarchical fault~mode model.

20
test_rigs/Makefile Normal file
View File

@ -0,0 +1,20 @@
#
paper: paper.tex test_rigs_paper.tex
#latex paper.tex
#dvipdf paper pdflatex cannot use eps ffs
pdflatex paper.tex
mv paper.pdf test_rigs.pdf
okular test_rigs.pdf
# Remove the need for referncing graphics in subdirectories
#
test_rigs_paper.tex: test_rigs.tex paper.tex
cat test_rigs.tex | sed 's/test_rigs\///' > test_rigs_paper.tex
bib:
bibtex paper

31
test_rigs/paper.tex Normal file
View File

@ -0,0 +1,31 @@
\documentclass[a4paper,10pt]{article}
\usepackage{graphicx}
\usepackage{fancyhdr}
\usepackage{tikz}
\usepackage{amsfonts,amsmath,amsthm}
\input{../style}
\usepackage{ifthen}
\newboolean{paper}
\setboolean{paper}{true} % boolvar=true or false
%\newtheorem{definition}{Definition:}
\begin{document}
\pagestyle{fancy}
%\outerhead{{\small\bf Statistical Basis for Current Static Analysis Methodologies}}
%\innerfoot{{\small\bf R.P. Clark } }
% numbers at outer edges
\pagenumbering{arabic} % Arabic page numbers hereafter
\author{R.P.Clark}
\title{FMMD used to assist the design of production test rigs}
\maketitle
\input{test_rigs_paper}
\bibliographystyle{plain}
\bibliography{../vmgbibliography,../mybib}
\today
\end{document}

90
test_rigs/test_rigs.tex Normal file
View File

@ -0,0 +1,90 @@
\ifthenelse {\boolean{paper}}
{
\abstract{
This paper describes how the Failure Mode Modular De-composition (FMMD) methodology
can be applied to the design of automated production test rigs
analysis.
%
Test rigs are often used as part of the production process
to ensure that the SYSTEM is not only operating
correctly but also calibrated where necessary.
%
% WHAT IS DID
Mention Chris Garret and Maikowqski theses : both directly relevant.
% WHAT I FOUND
From the FMMD data model it is possible to link
sub-systems under test to
{\dcs} determined from the FMMD process.
Armed with this knowledge
the tester can be pointed to the
likely faulty components.
% WHY YOU WOULD WANT TO READ IT
This feature of FMMD proides another tool in the safety engineers
repotiore, one that can shake out difficult to find
component failures from a high level test result failure.
}
}
{
\paragraph{Chapter overview}
This chapter describes how the % Failure Mode Modular De-composition (FMMD)
FMMD methodology
can be applied to the problems of
test rig design and construction.
%
%
Test rigs are often used as part of the production process
to ensure that the SYSTEM is not only operating
correctly but also calibrated where necessary.
%
% WHAT IS DID
Mention Chris Garret and Maikowqski theses : both directly relevant.
% WHAT I FOUND
From the FMMD data model it is possible to link
sub-systems under test to
{\dcs} determined from the FMMD process.
Armed with this knowledge
the tester can be pointed to the
likely faulty components.
% WHY YOU WOULD WANT TO READ IT
This feature of FMMD proides another tool in the safety engineers
repotiore, one that can shake out difficult to find
component failures from a high level test result failure.
}
\section{Introduction}
\ifthenelse {\boolean{paper}}
{
paper
}
{
chapter
}
\subsection{Description of a typical `test rig'}
Outline the fmmd process.
Show modules
which would be testable by a test rig
values read or logical conditions from {\dcs}
at a mid-level.
Trace a theoretical example and show how FMMD detects the
possible causes of the test rig failure.
Exlain why this would save time and money, and possibly
because testing is typically done in house
reveal any unknown failure modes of {\dcs} or even base components.

6
thesis.tex
View File

@ -132,9 +132,15 @@
Safety critical in that it must not overheat, and that it must alarm
for incorrect temperature.
\chapter{Modelling and Uncovering Common Mode Failures using FMMD}
\input{common_mode/common_mode}
\chapter{FMMD Used as a design aide}
\input{fmmd_design_aide/fmmd_design_aide}
\chapter{FMMD used to aid the design of production test rigs}
\input{test_rigs/test_rigs}
\chapter{FMMD use throughout product lifecycle}
\input{lifecycle_modelling/lifecycle_modelling}