J. Howse comments on fmmd_concept from 07JAN2011
implemented, except for the WEAKNESS OF ALL METHODOLOGIES THE SAME (copypasta...) Merge branch 'master' of dev:/home/robin/git/thesis Conflicts: fmmd_concept/fmmd_concept.tex fmmd_design_aide/fmmd_design_aide.tex
This commit is contained in:
commit
d485131a5c
@ -10,14 +10,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.
|
||||
|
||||
%%
|
||||
%% What I have done
|
||||
%%
|
||||
The four main static failure mode analysis methodologies were examined and
|
||||
in the context of newer European safety standards, assessed.
|
||||
Some of the deficiencies identified in these methodologies lead to
|
||||
Some of the deficiencies identified in these methodologies led to
|
||||
a wish list for a more rigorous methodology.
|
||||
|
||||
%%
|
||||
%% What I have found
|
||||
%%
|
||||
From the wish list
|
||||
@ -45,14 +45,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.
|
||||
|
||||
%%
|
||||
%% What I have done
|
||||
%%
|
||||
The four main static failure mode analysis methodologies were examined and
|
||||
in the context of newer European safety standards, assessed.
|
||||
Some of the defeciencies identified in these methodologies lead to
|
||||
Some of the deficiencies identified in these methodologies led to
|
||||
a wish list for a more ideal methodology.
|
||||
|
||||
%%
|
||||
%% What I have found
|
||||
%%
|
||||
From the wish list %
|
||||
@ -205,7 +205,7 @@ Let N be the number of components in our system, and K be the average number of
|
||||
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.}
|
||||
will be $(N-1) \times N \times K$, in effect a set cross product.
|
||||
will be $(N-1) \times N \times K$, in effect a very large set cross product.
|
||||
|
||||
|
||||
Complicate this further with applied states or environmental conditions
|
||||
@ -217,7 +217,8 @@ 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
|
||||
additional cross product factor,
|
||||
additional %cross product
|
||||
factor,
|
||||
$(N-1) \times N \times K \times E$.
|
||||
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
|
||||
@ -290,7 +291,7 @@ on SYSTEM level errors which have been investigated.
|
||||
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{bfmea}) of the identified SYSTEM failure,
|
||||
It is based on a simple equation where $S$ ranks the severity (or cost \cite{bfmea}) of the identified SYSTEM failure,
|
||||
$O$ its occurrence\footnote{The occurrence $O$ is the
|
||||
probability of the failure happening.},
|
||||
and $D$ giving the failures detectability\footnote{Detectability: often failures
|
||||
@ -299,7 +300,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 the $RPN$ values being the most urgent.
|
||||
a prioritised `todo list', with higher $RPN$ values being the most urgent.
|
||||
|
||||
|
||||
\subsubsection{ FMEA weaknesses }
|
||||
@ -310,13 +311,13 @@ a prioritised `todo list', with higher the $RPN$ values being the most urgent.
|
||||
\end{itemize}
|
||||
|
||||
\paragraph{Note.} FMEA is sometimes used in its literal sense, that is to say
|
||||
Failure Mode Effects analysis, simply looking at a systems internal failure
|
||||
Failure Mode Effects analysis, simply looking at a systems' internal failure
|
||||
modes and determining what may happen as a result.
|
||||
FMEA described in this section (\ref{pfmea}) is sometimes called `production FMEA'.
|
||||
|
||||
\subsection{FMECA}
|
||||
|
||||
Failure mode, effects, and criticality analysis (FMECDA) extends FMEA.
|
||||
Failure mode, effects, and criticality analysis (FMECA) extends FMEA.
|
||||
This is a bottom up methodology, which takes component failure modes
|
||||
and traces them to the SYSTEM level failures.
|
||||
%
|
||||
@ -364,9 +365,9 @@ Again this essentially produces a prioritised `todo' list.
|
||||
|
||||
\subsection { FMEDA or Statistical Analyis }
|
||||
|
||||
Failure Modes, Effects, and Diagnostic Analysis (FMEDA).
|
||||
|
||||
This is a process that takes all the components in a system,
|
||||
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
|
||||
ties them to possible SYSTEM level events/failure modes.
|
||||
%
|
||||
@ -576,7 +577,7 @@ be linked to a dangerous system level failure in an FMEDA study.
|
||||
%
|
||||
%%- IS THIS TRUE IS THERE A BETA FACTOR IN FMEDA????
|
||||
%%-
|
||||
%A $\beta$ factor, the hueristically defined probability
|
||||
%A $\beta$ factor, the heuristically defined probability
|
||||
%of the failure causing the system fault may be applied.
|
||||
%
|
||||
%In FMEDA there is no detailed analysis of the failure mode behaviour
|
||||
@ -744,7 +745,7 @@ functional group, and determine the ways in which it, rather than its
|
||||
components, can fail.
|
||||
%
|
||||
By doing this, the natural process whereby symptoms of the {\fg}
|
||||
(which can potentially be caused by more then one component failure mode)
|
||||
(which can potentially be caused by more than one component failure mode)
|
||||
are extracted.
|
||||
%
|
||||
The number of symptoms will be less than or equal to the number
|
||||
@ -783,7 +784,7 @@ is a small set of components that perform a simple
|
||||
task.
|
||||
%
|
||||
%The functional group should perform a clearly defined task.
|
||||
The design engineer must chose the components that form a {\fg}.
|
||||
The design engineer must choose the components that form a {\fg}.
|
||||
It should be possible to consider the {\fg} as a component or
|
||||
black box, performing a given function.
|
||||
The {\fg} should be chosen to be as small
|
||||
@ -802,7 +803,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 w.r.t. 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.
|
||||
%
|
||||
@ -841,8 +842,7 @@ failure.
|
||||
%In FTA terminology, a list of possible
|
||||
%causes for a SYSTEM level failure is known as a `cut set' \cite{nasafta}\cite{nucfta}.
|
||||
If statistical models exist for the component failure modes
|
||||
these failure causation trees (or minimal cut sets
|
||||
\footnote{In FTA terminology a minimal cut set is the branch of a
|
||||
these failure causation trees (or minimal cut sets\footnote{In FTA terminology a minimal cut set is the branch of a
|
||||
fault tree, from the top SYSTEM level to the bottom, with the least number
|
||||
of base component failure modes. If a single base component failure mode can cause
|
||||
a SYSTEM level error this is usually considered a liability.})
|
||||
@ -872,7 +872,7 @@ of the components included in the {\fg} from which it was derived.
|
||||
%
|
||||
Because common symptoms are being collected, as we build the tree upward
|
||||
the number of failure modes decreases (or exceptionally stays the same)
|
||||
at each level.\footnote{In very unusual cases where the none
|
||||
at each level.\footnote{In very unusual cases where the known
|
||||
failure modes of a {\fg} can be collected into symptoms,
|
||||
the number of failure modes from its components would be the
|
||||
same as the number of failure modes in the component derived from it.}
|
||||
@ -925,7 +925,7 @@ new {\fg}s and we can build a hierarchical `failure~mode' model of the SYSTEM.
|
||||
\label{fig:fmmd_hierarchy}
|
||||
\end{figure}
|
||||
|
||||
A {\fg} is a set components (each with a set of of failure modes)
|
||||
A {\fg} is a set of components (each with a set of of failure modes)
|
||||
that collectively group together to serve some purpose (to perform some function),
|
||||
and derived components are determined
|
||||
from analysis and symptom collection
|
||||
@ -990,7 +990,7 @@ For instance a system may be specified for
|
||||
$0\oc$ to $85\oc$ operation, but some components
|
||||
may show failure behaviour between $60\oc$ and $85\oc$
|
||||
\footnote{Opto-islolators typically show marked performance decrease after
|
||||
60oC \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
|
||||
$60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
|
||||
Other components may operate comfortably within that whole temperature range specified.
|
||||
Environmental conditions will have an effect on the {\fg} and the {\dc}
|
||||
but they will have specific effects on individual components.
|
||||
@ -1146,7 +1146,7 @@ of A multiplied by the probability of Q).
|
||||
If we wish to dynamically model the conditional failure
|
||||
an attribute to the failure~modes must be added
|
||||
that can reference other failure~modes and environmental conditions.
|
||||
An UML diagram with inhibit conditions added is shown in figure \ref{fig:umlconcept2}.
|
||||
A UML diagram with inhibit conditions added is shown in figure \ref{fig:umlconcept2}.
|
||||
|
||||
\subsection{Safe Dangerous, Detected and Undetected.}
|
||||
|
||||
@ -1174,7 +1174,9 @@ for a single base~component failure mode minimal cut set~\cite{nucfta}.
|
||||
\end{figure}
|
||||
|
||||
|
||||
\subsection{Advantages of FMMD Methodology}
|
||||
\subsection{Aims of FMMD Methodology}
|
||||
|
||||
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}
|
||||
\item It can be checked automatically that all component failure modes have
|
||||
@ -1200,12 +1202,13 @@ chosing {\fg}s and working bottom-up this hierarchical trait will occur as a nat
|
||||
\item It is possible to model multiple failure modes.
|
||||
\end{itemize}
|
||||
|
||||
\section{Re-Factoring the UML Model}
|
||||
|
||||
The UML models thus far in this
|
||||
\ifthenelse {\boolean{paper}}
|
||||
{
|
||||
%paper
|
||||
\pagebreak[4]
|
||||
\section{Re-Factoring the UML Model}
|
||||
The UML models thus far in this
|
||||
have been used to develop the data relationships required to perform FMMD analysis.
|
||||
This section re-organises and rationalises the UML model.
|
||||
We want to be able to use {\dcs} in functional groups.
|
||||
@ -1225,7 +1228,9 @@ The re-factored UML diagram is shown in figure \ref{fig:refactored_uml}.
|
||||
}
|
||||
{
|
||||
% chapter
|
||||
The terms used in FMMD and the UML data model are refined in the
|
||||
\section{Re-Factoring the UML Model}
|
||||
This chapter has used UML diagrams to develop the data types required to implment FMMD.
|
||||
The terms used in FMMD and the UML data model are further refined in
|
||||
chapter \ref{defs}.
|
||||
}
|
||||
|
||||
@ -1247,3 +1252,4 @@ The author believes it addresses many short comings in current static failure mo
|
||||
\today
|
||||
|
||||
%% $$\frac{-b\pm\sqrt{ {b^2-4ac}}}{2a}$$
|
||||
%\today
|
||||
|
||||
@ -77,7 +77,7 @@ The `undetectable' failure modes undertsandably, are the most worrying for the s
|
||||
EN61058, the statistically based European Norm, using ratios
|
||||
of detected and undetected system failure modes to
|
||||
classify the sytems safety levels and describes sub-clasifications
|
||||
for detected and undetected failure modes \cite{en61508}.
|
||||
for detected and undetected failure modes~\cite{en61508}.
|
||||
|
||||
%It is these that are, generally the ones that stand out as single
|
||||
%failure modes.
|
||||
@ -231,7 +231,7 @@ and this error symptom, `low\_reading' would mean our plant could
|
||||
beleive that the temperature reading is lower than it actually is.
|
||||
To take an example from a K type thermocouple, the offset of 1.86mV
|
||||
%from the potential divider represents amplified to
|
||||
would represent $\approx \; 46\,^{\circ}{\rm C}$ \cite{eurothermtables} \cite{aoe}.
|
||||
would represent $\approx \; 46\,^{\circ}{\rm C}$~\cite{eurothermtables}~\cite{aoe}.
|
||||
|
||||
%\clearpage
|
||||
\subsection{Undetected Failure Mode: Incorrect Reading}
|
||||
@ -500,7 +500,7 @@ We can surmise the symptoms in a list.
|
||||
%\clearpage
|
||||
\subsection{OP-AMP FIT Calculations}
|
||||
The DOD electronic reliability of components
|
||||
document MIL-HDBK-217F\cite{mil1992}[5.1] gives formulae for calculating
|
||||
document MIL-HDBK-217F~\cite{mil1991}[5.1] gives formulae for calculating
|
||||
the
|
||||
%$\frac{failures}{{10}^6}$
|
||||
${failures}/{{10}^6}$ % looks better
|
||||
|
||||
@ -42,11 +42,15 @@ Transitioning between one stage and another depends on decisions made from
|
||||
variable states. This corresponds to the standard software structures, if-then-else
|
||||
do-while etc.
|
||||
|
||||
At a program flow stage, the software may initiate actions. Typically, in an embedded
|
||||
system, a micro controller will read from external sensors, and then apply
|
||||
Generally the flow of data follows a pattern of afferent, transform and efferent.
|
||||
That is to say data is input, processed and data is output.
|
||||
|
||||
%At a program flow stage, the software may initiate actions.
|
||||
In a safety critical control system
|
||||
typically, an embedded
|
||||
electro-mechanical system, a micro controller will read from external sensors, and then apply
|
||||
outputs to control the equipment under supervision.
|
||||
|
||||
More generally the flow of data follows a pattern of afferent, transform and efferent.
|
||||
|
||||
\subsection{Afferent, Transform and Afferent Data Flow}
|
||||
|
||||
|
||||
Loading…
Reference in New Issue
Block a user