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
This commit is contained in:
Robin Clark 2011-01-21 17:55:57 +00:00
commit e3ddd1194d
6 changed files with 110 additions and 63 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}
\label{sec:unitarystate}
\paragraph{Design Descision/Constraint}
An important factor in defining a set of failure modes is that they
should represent the failure modes as simply and minimally as possible.

2
eulerg/eulerg.tex
View File

@ -330,5 +330,7 @@ The order of area operations is generally\footnote{In the case where the diagram
reduced by requiring several $K.|P|.2^{|P|}$
instead of $N.2^N$ as $K < N$.
This has effectively reduced the order of the searching algorithm from exponential to polynomial order.
\vspace{40pt}

117
fmmd_concept/fmmd_concept.tex
View File

@ -7,6 +7,14 @@ creating failure mode models of safety critical systems, which
has a common notation
for mechanical, electronic and software domains and applies an
incremental and rigorous approach.
%This paper describes how the proposed methodology
%functions, given requirements and constraints (such as number of combinations
%of failure causes for flat ).
%It describes the need for the new methodology to be bottom-up, and
%then the need for incremental modularisation
%to build a fault mode hierarchy, which leads to the conceopt of functional grouping,
%analysis of those groupings, and from that
%the creation of derived components.
%%
%% What I have done
%%
@ -43,6 +51,15 @@ has a common notation
for mechanical, electronic and software domains and applies an
incremental and rigorous approach.
%%
%This chapter describes how the proposed methodology functions
%given requirements and constraints such as the number of combinations
%of failure causes.
%It describes the need for the new methodology to be bottom-up, and
%then the need for incremental modularisation
%to build a fault mode hierarchy, which leads to the conceopt of functional grouping,
%analysis of those groupings, and from that
%the creation of derived components.
%% What I have done
%%
The four main static failure mode analysis methodologies were examined and
@ -98,7 +115,7 @@ of analysis.
The FMMD
methodology provides a detailed, hierarchical, incremental and analytical
modelling system which will create a failure mode model from which
the data models from FTA, FMEA, FMECA and FMEDA % (the statistical approach)
the data models for FTA, FMEA, FMECA and FMEDA % (the statistical approach)
can be
derived. % if required.
An FMMD model is effectively a super set of all the four traditional models.
@ -106,10 +123,10 @@ It also focuses on component interaction within the model,
something not formally considered in the four established methodologies.
%
In addition it applies rigorous checking in all the analysis stages
ensuring that all component failure modes must be considered in the model.
ensuring that \textbf{all} component failure modes must be considered in the model.
%
\paragraph{FMMD Process outline.}
\paragraph{FMMD process outline.}
This methodology has been named Failure Mode Modular De-composition (FMMD)
because it decomposes a SYSTEM into a hierarchy of modules or {\dc}s.
This
@ -123,7 +140,7 @@ chapter
presents the design considerations that motivated and provided the specification for
the FMMD methodology.
%
It first reviews the four traditional
Firstly it briefly reviews the four traditional
static failure mode analysis methodologies and
lists their known weaknesses. A wish list is then drawn up
addressing these weaknesses and adding some extra requirements.
@ -135,7 +152,8 @@ of components, {\fgs}, and then analysing how they can fail.
\input{./shortfg}
\paragraph{Micro Vs. Macro failure mode analysis.}
This analysis is performed using FMEA from a micro rather than a macro perspective.
The FMMD analysis is performed using failure mode effects analysis
from a micro rather than a macro perspective.
Thus instead of looking at component failure modes and determining how
they {\em may} cause a failure at SYSTEM level, we are looking at how
they {\em will} affect the component's local {\fg}.
@ -145,7 +163,8 @@ at higher levels of analysis, until we have a complete
hierarchy representing the failure behaviour of the SYSTEM.
%
Because all the failure modes of all the components
are held in a computer program, we can determine if the model is complete
are held in a computer program, we can determine if the model has complete coverage
for component failure modes
(i.e. all component failure modes have been included in the model).
@ -198,7 +217,7 @@ and therefore human judgement must be used to
decide which interactions could be 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 base~component can fail). The total number of base component failure modes
(ways in which a base~component can fail). The total number of base component failure modes
is $N \times K$. To examine the effect that one failure mode has on all
the other components\footnote{A base component failure will typically affect the sub-system
it is part of, and create a failure effect at the SYSTEM level.}
@ -213,15 +232,16 @@ Or we may have a mechanical device that has a different
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 presented with an
in a system, and $A$ the number of applied states,
the job of the bottom-up analyst is presented with two
additional %cross product
factor,
$(N-1) \times N \times K \times E$.
factors,
$(N-1) \times N \times K \times E \times A$.
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.
and heater circuit.} into this, say $N=100$, $K=2.5$, $A=2$, and $E=10$
we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $.
To look in detail at a half of a million test cases is obviously impractical.
If we were to consider multiple simultaneous failure modes,
we have yet another cross product of checks to be performed.
@ -230,7 +250,8 @@ For instance looking at double simultaneous failure modes, where $\#C$
is the number of checks to perform
the equation reads $\#C = (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
The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes\footnote{Often component failures, rather than individual component
failure modes are used, making the analysis process less precise.} and link them
to SYSTEM level failure modes. Because of the astronomical number of possible interactions,
some valid ones are in danger of being missed, we can term this analysis as a `leap~of~faith'
(i.e. leaping from from the
@ -273,9 +294,9 @@ Consequently it was not designed to guarantee to covering all component failure
and has no rigorous in-built safeguards to ensure coverage of all possible
system level outcomes.
Also each system level error (or undesireable event) requires its own FTA tree.
This increase the amount of work to do, and in the case of updates to
This increases the amount of work to do, and in the case of updates to
particular sub-systems, introduces the requirement to update every FTA
tree modelling that sub-system.
tree modelling that use the affected sub-system.
\subsubsection{ FTA weaknesses }
\begin{itemize}
@ -304,7 +325,7 @@ Consider an unused feature failing.}. Muliplying these
together,
gives a risk probability number (RPN), given by $RPN = S \times O \times D$.
This gives in effect
a prioritised `todo list', with higher $RPN$ values being the most urgent.
a prioritised `to~do~list', with higher $RPN$ values being the most urgent.
\subsubsection{ FMEA weaknesses }
@ -377,7 +398,7 @@ makes the factor less statistically reliable.
Failure Modes, Effects, and Diagnostic Analysis (FMEDA)
% This
is a process that takes all the components in a system,
and using the failure modes of those components; the investigating engineer
and using the failure modes of those components, the investigating engineer
ties them to possible SYSTEM level events/failure modes.
%
This technique
@ -407,7 +428,8 @@ to succeeding to operate correctly on demand.
}
{
FMEDA is a statistical analysis methodology and is used from one of two perspectives,
Probability of Failure on Demand (PFD) (see \ref{survey:pfd}), and Probability of Failure
Probability of Failure on Demand (PFD) (see \ref{survey:pfd})
, and Probability of Failure
in continuous Operation, or Failure in Time (FIT) (see \ref{survey:fit}).
}
@ -420,7 +442,11 @@ Each component is analysed in terms of how its failure
would affect the system.
Failure rates of individual components in the SYSTEM
are calculated based on component type and
environmental conditions. The SYSTEM errors are categorised as `safe' or `dangerous'.
environmental conditions.
%The SYSTEM errors are categorised as `safe' or `dangerous'.
%
%Statistical data exists for most component types \cite{mil1992}.
%
@ -457,7 +483,7 @@ based on heuristics or field data.
\paragraph{Determine Detectable and Undetectable Failures.}
Each safe and dangerous failure mode is now
classified as detectable or un-detectable.
For the higher integrity levels, EN61508 assumes that products have a high proportion of
For the higher integrity levels, EN61508 requires that products have a high proportion of
self checking features.
%
This gives us four level failure mode classifications:
@ -676,7 +702,7 @@ further into the way the system works and is built.
\paragraph{Need for a `bottom-up' system de-composition.}
There is an apparent conflict here. The natural way to
There is an apparent conflict here as de-composition ormally implies a top-down approach. The natural way to
de-compose a system is from the top down.
%
If we do this though, we do not naturally include
@ -716,10 +742,16 @@ The base components will typically have several failure modes each.
Given a typical embedded system may have hundreds of components,
this means that we would still have to tie base component failure modes
to SYSTEM level errors.
%
The problem with this is that the base component failure mode under investigation,
effects are not rigorously examined in relation to functionally adjacent components.
Thus there is the `possibility to miss failure mode effects
at the much higher SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies.
are not rigorously examined in relation to functionally adjacent components.
%
If failures modes could be collected and simplified somehow
at each stage in a hierarchy of {\fgs}, the functionally adjacent
ideal would be met, and as we progress up the hierarchy the number
of failure modes should decrease.
%Thus there is the `possibility to miss failure mode effects
%at the much higher SYSTEM level' criticism of the FTA, FMEDA and FMECA methodologies.
%%%
%%% OK Got up to here Lunchtime edit 06DEC2010.............
@ -798,6 +830,9 @@ In this way as we build the hierarchy, we naturally abstract the
failure mode behaviour, but can check that all failure modes in
the hierarchy have been considered and tied to causing symptoms.
\paragraph{Design Decision: Derived components must be determined from functional groups.}
The symptoms obtained from analysing a {\fg} will be used as the `failure~modes'
of its corresponding {\dc}.
\paragraph{Incremental Stages and \dcs .}
We can use incremental stages to build the hierarchy.
@ -827,7 +862,7 @@ With the results from the test cases we will now have the ways in which the
We can refine this further, by grouping the common symptoms, or results that
are the same failure {\wrt} 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 treat the {\fg} as a component, and create a corresponding {\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
as its failure modes.
@ -835,7 +870,7 @@ as its failure modes.
This {\dc} can be used to build higher level
{\fg}s, and this will naturally form a hierarchy.
This hierarchy can be extended until it encompasses
an entire system.
an entire SYSTEM.
%
It can be considered complete when
all failure modes from all components are included in the model
@ -871,7 +906,7 @@ a SYSTEM level error this is usually considered a liability.})
can be used to calculate Mean Time to Failure (MTTF) or
Probability of Failure on demand (PFD) figures.
Contrast the analytical capability of FMMD with the
methodologies where the component failure modes are linked
methodologies where the component failure modes/components are linked
directly to SYSTEM failure modes with no analysis stages in between.
@ -890,7 +925,7 @@ A derived component when created must always have a greater $\alpha$ value than
of the components included in the {\fg} from which it was derived.
\paragraph{Natural Reduction in number of failure modes with abstraction level}
\paragraph{Natural Reduction in number of failure modes with abstraction level.}
%
Because common symptoms are being collected, as we build the tree upward
the number of failure modes decreases (or exceptionally stays the same)
@ -917,8 +952,8 @@ Functional groups are collections of components
that work together to perform a simple function.
%
We can perform a failure mode effects analysis on each of the component failure
modes within a {\fg}. Because we can implement the process in software we can
thus ensure that all component failure modes
modes within a {\fg}. Because we can guide the process in software we can
ensure that all component failure modes
are included in the model.
%
We can then treat the {\fg} as a `black box' or component in its own right.
@ -1116,11 +1151,6 @@ at each FMMD stage.
Where appropriate, multiple simultaneous failures can be modelled by
introducing test~cases where the conjunction of failure modes is considered.
\subsubsection {Inhibit Conditions}
Some failure modes only occur when another failure has occurred, or
due to an environmental condition reaching a critical value. This is specifically
dealt with using the FTA methodology~\cite{nucfta}[IV 9].
An example FTA inhibit gate is shown in figure \ref{fig:inhibitconcept}.
\begin{figure}
\centering
@ -1161,6 +1191,11 @@ An example FTA inhibit gate is shown in figure \ref{fig:inhibitconcept}.
\label{fig:inhibitconcept}
\end{figure}
\subsubsection {Inhibit Conditions}
Some failure modes only occur when another failure has occurred, or
due to an environmental condition reaching a critical value. This is specifically
dealt with using the FTA methodology~\cite{nucfta}[IV 9].
An example FTA inhibit gate is shown in figure \ref{fig:inhibitconcept}.
\paragraph{Static or Dynamic Modelling of Inhibit}
If the model is static we can consider the conditional failure,
at a lower probability of occurring (i.e. the probability
@ -1197,7 +1232,7 @@ for a single base~component failure mode minimal cut set~\cite{nucfta}.
\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.
\begin{itemize}
@ -1262,6 +1297,14 @@ This
\ifthenelse {\boolean{paper}}
{
paper
describes how the FMMD methodology
functions, given requirements and constraints such as the number of combinations
of failure causes.
It describes the need for the new methodology to be bottom-up, and
then the need for incremental modularisation
to build a fault mode hierarchy, which leads to the conceopt of functional grouping,
analysis of those groupings, and from that
the creation of derived components.
}
{
chapter

19
symptom_ex_process/algorithm.tex
View File

@ -6,8 +6,8 @@
The algorithm for {\em symptom extraction} is described in
this section
%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$
and converts it to a derived~component/sub-system $DC$.
%The sub-system $SS$ is a collection
@ -15,7 +15,8 @@ and converts it to a derived~component/sub-system $DC$.
Note that
$DC$ is a derived component at a higher level of fault analysis abstraction
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.
@ -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.
%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.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
@ -82,7 +83,7 @@ $$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
\end{algorithmic}
\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
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
@ -179,7 +180,7 @@ given by
$$ 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)
The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component.
\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
}
{
This is discussed in section \ref{unitarystate}.
This is discussed in section \ref{sec:unitarystate}.
}
%%
%% Algorithm 2
@ -337,9 +338,11 @@ The analysis is primarily a human activity.
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
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
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:
\paragraph{Symptom Extraction Objective}
\paragraph{Symptom Extraction Objective.}
The objective of `symptom abstraction' is to analyse the functional~group and find
how it can 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
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
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}$.
@ -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.
%
\paragraph{Environmental Conditions or Applied States}
\paragraph{Environmental Conditions or Applied States.}
Each test case must be considered for all applied/operational states and
%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.
%%-
\paragraph{Symptom Identification}
\paragraph{Symptom Identification.}
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.
@ -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
some of these into common `symptoms'. Some test cases may cause
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 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.
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}.
Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined
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 \} $$
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.
i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ would have been $ \{ SP1, SP2, g_6 \}$.
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)$ could have been $ \{ SP1, SP2, g_6 \}$.
Because the process can be computerised, we can easily flag symptoms that have not been
included as failure modes in a {\dc}.
% 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
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

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.
From the model created by the FMMD methodology, statistical, FTA and FMEA models
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.
FMMD can model electrical, mechanical and software failures using a common notation,
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.
@ -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
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
of the components.
of components\cite{mil1992}.
%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
%and is the way in which FTA\cite{nucfta} analyses a System
%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
may themselves be sub-systems. However each `component'
will have a fault/failure behaviour and it should
@ -135,8 +135,7 @@ for each `component'.
If we look at the sound system example,
the CD~player could fail in several distinct ways,
and this could be due to a large number of
component failure modes.
and this could have been caused by a number of component failure modes.
%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 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
for the smallest `functional~groups' of components within a system.
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
of its component failure modes.
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.
%The goal here is to know how it will behave under fault conditions !