Merge branch 'master' of dev:/home/robin/git/thesis
This commit is contained in:
commit
e3ddd1194d
@ -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.
|
||||||
|
@ -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|}$
|
reduced by requiring several $K.|P|.2^{|P|}$
|
||||||
instead of $N.2^N$ as $K < N$.
|
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}
|
\vspace{40pt}
|
||||||
|
|
||||||
|
@ -7,6 +7,14 @@ creating failure mode models of safety critical systems, which
|
|||||||
has a common notation
|
has a common notation
|
||||||
for mechanical, electronic and software domains and applies an
|
for mechanical, electronic and software domains and applies an
|
||||||
incremental and rigorous approach.
|
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
|
%% What I have done
|
||||||
%%
|
%%
|
||||||
@ -43,6 +51,15 @@ has a common notation
|
|||||||
for mechanical, electronic and software domains and applies an
|
for mechanical, electronic and software domains and applies an
|
||||||
incremental and rigorous approach.
|
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
|
%% What I have done
|
||||||
%%
|
%%
|
||||||
The four main static failure mode analysis methodologies were examined and
|
The four main static failure mode analysis methodologies were examined and
|
||||||
@ -98,7 +115,7 @@ of analysis.
|
|||||||
The FMMD
|
The FMMD
|
||||||
methodology provides a detailed, hierarchical, incremental and analytical
|
methodology provides a detailed, hierarchical, incremental and analytical
|
||||||
modelling system which will create a failure mode model from which
|
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
|
can be
|
||||||
derived. % if required.
|
derived. % if required.
|
||||||
An FMMD model is effectively a super set of all the four traditional models.
|
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.
|
something not formally considered in the four established methodologies.
|
||||||
%
|
%
|
||||||
In addition it applies rigorous checking in all the analysis stages
|
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)
|
This methodology has been named Failure Mode Modular De-composition (FMMD)
|
||||||
because it decomposes a SYSTEM into a hierarchy of modules or {\dc}s.
|
because it decomposes a SYSTEM into a hierarchy of modules or {\dc}s.
|
||||||
This
|
This
|
||||||
@ -123,7 +140,7 @@ chapter
|
|||||||
presents the design considerations that motivated and provided the specification for
|
presents the design considerations that motivated and provided the specification for
|
||||||
the FMMD methodology.
|
the FMMD methodology.
|
||||||
%
|
%
|
||||||
It first reviews the four traditional
|
Firstly it briefly reviews the four traditional
|
||||||
static failure mode analysis methodologies and
|
static failure mode analysis methodologies and
|
||||||
lists their known weaknesses. A wish list is then drawn up
|
lists their known weaknesses. A wish list is then drawn up
|
||||||
addressing these weaknesses and adding some extra requirements.
|
addressing these weaknesses and adding some extra requirements.
|
||||||
@ -135,7 +152,8 @@ of components, {\fgs}, and then analysing how they can fail.
|
|||||||
\input{./shortfg}
|
\input{./shortfg}
|
||||||
|
|
||||||
\paragraph{Micro Vs. Macro failure mode analysis.}
|
\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
|
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 may} cause a failure at SYSTEM level, we are looking at how
|
||||||
they {\em will} affect the component's local {\fg}.
|
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.
|
hierarchy representing the failure behaviour of the SYSTEM.
|
||||||
%
|
%
|
||||||
Because all the failure modes of all the components
|
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).
|
(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.
|
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
|
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
|
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
|
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.}
|
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.
|
failure mode behaviour for say, different ambient pressures or temperatures.
|
||||||
|
|
||||||
If $E$ is the number of applied states or environmental conditions to consider
|
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
|
additional %cross product
|
||||||
factor,
|
factors,
|
||||||
$(N-1) \times N \times K \times E$.
|
$(N-1) \times N \times K \times E \times A$.
|
||||||
If we put some typical very small embedded system numbers\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
|
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$
|
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 = 247500 $.
|
we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $.
|
||||||
To look in detail at a quarter of a million test cases is obviously impractical.
|
To look in detail at a half of a million test cases is obviously impractical.
|
||||||
|
|
||||||
If we were to consider multiple simultaneous failure modes,
|
If we were to consider multiple simultaneous failure modes,
|
||||||
we have yet another cross product of checks to be performed.
|
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
|
is the number of checks to perform
|
||||||
the equation reads $\#C = (N-2) \times (N-1) \times N \times K \times E$.
|
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,
|
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'
|
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
|
(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
|
and has no rigorous in-built safeguards to ensure coverage of all possible
|
||||||
system level outcomes.
|
system level outcomes.
|
||||||
Also each system level error (or undesireable event) requires its own FTA tree.
|
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
|
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 }
|
\subsubsection{ FTA weaknesses }
|
||||||
\begin{itemize}
|
\begin{itemize}
|
||||||
@ -304,7 +325,7 @@ Consider an unused feature failing.}. Muliplying these
|
|||||||
together,
|
together,
|
||||||
gives a risk probability number (RPN), given by $RPN = S \times O \times D$.
|
gives a risk probability number (RPN), given by $RPN = S \times O \times D$.
|
||||||
This gives in effect
|
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 }
|
\subsubsection{ FMEA weaknesses }
|
||||||
@ -377,7 +398,7 @@ makes the factor less statistically reliable.
|
|||||||
Failure Modes, Effects, and Diagnostic Analysis (FMEDA)
|
Failure Modes, Effects, and Diagnostic Analysis (FMEDA)
|
||||||
% This
|
% This
|
||||||
is a process that takes all the components in a system,
|
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.
|
ties them to possible SYSTEM level events/failure modes.
|
||||||
%
|
%
|
||||||
This technique
|
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,
|
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}).
|
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.
|
would affect the system.
|
||||||
Failure rates of individual components in the SYSTEM
|
Failure rates of individual components in the SYSTEM
|
||||||
are calculated based on component type and
|
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}.
|
%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.}
|
\paragraph{Determine Detectable and Undetectable Failures.}
|
||||||
Each safe and dangerous failure mode is now
|
Each safe and dangerous failure mode is now
|
||||||
classified as detectable or un-detectable.
|
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.
|
self checking features.
|
||||||
%
|
%
|
||||||
This gives us four level failure mode classifications:
|
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.}
|
\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.
|
de-compose a system is from the top down.
|
||||||
%
|
%
|
||||||
If we do this though, we do not naturally include
|
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,
|
Given a typical embedded system may have hundreds of components,
|
||||||
this means that we would still have to tie base component failure modes
|
this means that we would still have to tie base component failure modes
|
||||||
to SYSTEM level errors.
|
to SYSTEM level errors.
|
||||||
|
%
|
||||||
The problem with this is that the base component failure mode under investigation,
|
The problem with this is that the base component failure mode under investigation,
|
||||||
effects are not rigorously examined in relation to functionally adjacent components.
|
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.
|
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.............
|
%%% 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
|
failure mode behaviour, but can check that all failure modes in
|
||||||
the hierarchy have been considered and tied to causing symptoms.
|
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 .}
|
\paragraph{Incremental Stages and \dcs .}
|
||||||
We can use incremental stages to build the hierarchy.
|
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
|
We can refine this further, by grouping the common symptoms, or results that
|
||||||
are the same failure {\wrt} the {\fg}.
|
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
|
We can now create a new/{\dc} and assign it these common symptoms
|
||||||
as its failure modes.
|
as its failure modes.
|
||||||
@ -835,7 +870,7 @@ as its failure modes.
|
|||||||
This {\dc} can be used to build higher level
|
This {\dc} can be used to build higher level
|
||||||
{\fg}s, and this will naturally form a hierarchy.
|
{\fg}s, and this will naturally form a hierarchy.
|
||||||
This hierarchy can be extended until it encompasses
|
This hierarchy can be extended until it encompasses
|
||||||
an entire system.
|
an entire SYSTEM.
|
||||||
%
|
%
|
||||||
It can be considered complete when
|
It can be considered complete when
|
||||||
all failure modes from all components are included in the model
|
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
|
can be used to calculate Mean Time to Failure (MTTF) or
|
||||||
Probability of Failure on demand (PFD) figures.
|
Probability of Failure on demand (PFD) figures.
|
||||||
Contrast the analytical capability of FMMD with the
|
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.
|
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.
|
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
|
Because common symptoms are being collected, as we build the tree upward
|
||||||
the number of failure modes decreases (or exceptionally stays the same)
|
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.
|
that work together to perform a simple function.
|
||||||
%
|
%
|
||||||
We can perform a failure mode effects analysis on each of the component failure
|
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
|
modes within a {\fg}. Because we can guide the process in software we can
|
||||||
thus ensure that all component failure modes
|
ensure that all component failure modes
|
||||||
are included in the model.
|
are included in the model.
|
||||||
%
|
%
|
||||||
We can then treat the {\fg} as a `black box' or component in its own right.
|
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
|
Where appropriate, multiple simultaneous failures can be modelled by
|
||||||
introducing test~cases where the conjunction of failure modes is considered.
|
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}
|
\begin{figure}
|
||||||
\centering
|
\centering
|
||||||
@ -1161,6 +1191,11 @@ An example FTA inhibit gate is shown in figure \ref{fig:inhibitconcept}.
|
|||||||
\label{fig:inhibitconcept}
|
\label{fig:inhibitconcept}
|
||||||
\end{figure}
|
\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}
|
\paragraph{Static or Dynamic Modelling of Inhibit}
|
||||||
If the model is static we can consider the conditional failure,
|
If the model is static we can consider the conditional failure,
|
||||||
at a lower probability of occurring (i.e. the probability
|
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}
|
\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}
|
||||||
@ -1262,6 +1297,14 @@ This
|
|||||||
\ifthenelse {\boolean{paper}}
|
\ifthenelse {\boolean{paper}}
|
||||||
{
|
{
|
||||||
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
|
chapter
|
||||||
|
@ -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'.
|
||||||
|
@ -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
|
||||||
|
@ -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 !
|
||||||
|
Loading…
Reference in New Issue
Block a user