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

as 'read aloud' proof read by me & JMC

Browse Source
This commit is contained in:
Robin Clark 2011-06-27 17:04:14 +01:00
parent 463b660eac
commit 1b4aecc211
1 changed files with 57 additions and 42 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

99
fmmd_concept/System_safety_2011/submission.tex
View File

@ -10,8 +10,8 @@
\usepackage{lastpage}
\usetikzlibrary{shapes,snakes}
\newcommand{\tickYES}{\checkmark}
\newcommand{\fc}{\em fault scenario}
\newcommand{\fcs}{\em fault scenarios}
\newcommand{\fc}{fault~scenario}
\newcommand{\fcs}{fault~scenarios}
\date{}
%\renewcommand{\encodingdefault}{T1}
%\renewcommand{\rmdefault}{tnr}
@ -24,10 +24,10 @@
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
\newcommand{\fg}{functional~group}
\newcommand{\fgs}{functional~groups}
\newcommand{\dc}{\em derived~component}
\newcommand{\dcs}{\em derived~components}
\newcommand{\bc}{\em base~component}
\newcommand{\bcs}{\em base~components}
\newcommand{\dc}{derived~component}
\newcommand{\dcs}{derived~components}
\newcommand{\bc}{base~component}
\newcommand{\bcs}{base~components}
\newcommand{\irl}{in real life}
\newcommand{\enc}{\ensuremath{\stackrel{enc}{\longrightarrow}}}
\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}}
@ -108,16 +108,16 @@ A worked example is then presented, using the new methodology, which models the
behaviour of a non-inverting op-amp circuit.
Using the worked example the new methodology is evaluated.
Finally the desirable criteria list is presented as a check box table alongside
the four current methodologies.
four current methodologies.
}
%\paragraph{Current methodologies}
We briefly analyse four current methodologies.
Comprehensive overviews of these methodologies maybe found
Comprehensive overviews of these methodologies may be found
in ~\cite{safeware,sccs}.
\paragraph{Fault Tree Analysis (FTA)}
\paragraph{Fault Tree Analysis (FTA).}
FTA~\cite{nasafta,nucfta} is a top down methodology in which a hierarchical diagram is drawn for
each undesirable top level failure/event, presenting the conditions that must arise to cause
the event.
@ -133,7 +133,7 @@ or be used to determine system level errors other than those modelled.
%
Each FTA diagram models one top level event.
This creates duplication of modelled elements,
and there is no facility to cross check between diagrams. It has limited
and it is difficult to cross check between diagrams. It has limited
support for environmental and operational states.
@ -158,12 +158,12 @@ analyse how particular components may fail.
\paragraph{Failure Mode Effects Criticality Analysis (FMECA)} is a refinement of FMEA, using
extra variables: the probability of a component failure mode occurring,
the probability that this will cause a given top level failure, and the perceived
critically. It gives better estimations of product reliability/safety and the
criticality. It gives better estimations of product reliability/safety and the
occurrence of particular system failure modes than FMEA but has similar deficiencies.
\paragraph{Failure Modes, Effects and Diagnostic Analysis (FMEDA)} is a refinement of
FMEA and FMECA and models self-checking safety elements. It assigns two
FMEA and FMECA and in addition models self-checking safety elements. It assigns two
attributes to component failure modes: detectable/undetectable and safe/dangerous.
Statistical measures about the system can be made and used to classify a
safety integrity level. It allows designs with in-built safety features to be assessed.
@ -205,10 +205,13 @@ the bottom-up analyst is presented with two
additional %cross product
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$, $A=2$, and $E=10$
we have $99 \times 100 \times 2.5 \times 10 \times 2 = 495000 $.
%
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, sensors, an RS485 interface,
supporting circuitry and heater circuitry.}
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 $ checks to perform.
%
To look in detail at half a million fault~scenarios is obviously impractical.
% Requirements for an improved methodology The deficiencies identified in the
% current methodologies are used to establish criteria for an improved methodology.
@ -248,7 +251,7 @@ To look in detail at half a million fault~scenarios is obviously impractical.
%\section{Requirements for a new static failure mode Analysis methodology}
\section{Desirable Criteria.}
From the deficiencies outlined above, ideally we can form a set of desirable criteria for an enhanced failure mode methodology.
From the deficiencies outlined above, we can form a set of desirable criteria for an enhanced failure mode methodology.
{ %\small
\label{criteria}
\begin{enumerate}
@ -340,7 +343,7 @@ for its results, such as error causation trees.%, reliability and safety statis
% Any new static failure mode methodology must ensure that it
% represents all component failure modes and it therefore should be bottom-up,
% starting with individual component failure modes.
To ensure all component failure modes are represented the new methodology must be bottom-up.
To ensure all component failure modes are represented, the new methodology must be bottom-up.
%
This seems essential to satisfy criterion 2.
The proposed methodology is therefore a bottom-up process
@ -354,13 +357,19 @@ In order to address the state explosion problem, the process should be modular a
dealing with small groups of components at a time; this should address criterion 1.
%\paragraph{Outline of the Failure mode methodology.}
%
A {\em {\fg}}, is defined as a small collection of components
that interact to provide
a function or task within a system.
%
In the proposed methodology components are collected into functional groups
and each component failure (and optionally combinations) are considered in the
context of the {\fg}.
%% GARK
%
The component failures (and optional combinations) are termed {\fcs}. %`test~cases'.
The component failures (and optional combinations) are termed {\em{\fcs}}. %`test~cases'.
For each {\fc}
there will be a corresponding resultant failure, or `symptom', from the perspective of the {\fg}.
%
@ -378,14 +387,14 @@ A common symptom collection stage is now applied. Here common symptoms are colle
from the results of the {\fcs}. Because it is possible to model combinations of failures,
criterion 6 is satisfied.
%
With a collection of the {\fg} failure symptoms, we can create a {\dc}.
With a collection of the {\fg} failure symptoms, we can create a {\em{\dc}}.
The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from.
This satisfies criterion 4, as we can now treat {\dcs} as pre-analysed
modules available for re-use.
By using {\dcs} in higher level functional groups, a hierarchy can be built representing
the failure mode behaviour of a system. Because the hierarchy maintains information
linking the symptoms to {\fcs} to component failure modes, we have traceable
linking the symptoms to component failure modes (via {\fcs}), we have traceable
reasoning connections from base component failures to top level failures.
The traceability should satisfy criterion 5.
@ -458,12 +467,10 @@ to balance them against the positive input, giving the voltage gain ($G_v$)
defined by $ G_v = 1 + \frac{R2}{R1} $ at the output.
A functional group, is an ideally small collection of components
that interact to provide
a function or task within a system.
As the resistors work to provide a specific function, that of a potential divider,
we can treat them as a functional group. This functional group has two members, $R1$ and $R2$.
Using the EN298 specification for resistor failure ~\cite{en298}[App.A]
Using the EN298 specification for resistor failure~\cite{en298}[App.A],
we can assign failure modes of $OPEN$ and $SHORT$ to the resistors.
\ifthenelse {\boolean{dag}}
{
@ -599,8 +606,8 @@ This would mean the symptom of the failed potential divider would be that it
gives a high voltage output.%We can now consider the {\fg}
%as a component in its own right, and its symptoms as its failure modes.
From table \ref{pdfmea} we can see that resistor
failures modes lead to some common `symptoms'.
From table \ref{pdfmea} we can see that the resistor
failures modes lead to some common symptoms.
By drawing directed edges, from the failure modes to the symptoms
we can show the relationships between the component failure modes and resultant symptoms.
%The {\fg} can now be considered a derived component.
@ -880,8 +887,8 @@ and this is represented in table \ref{ampfmea}.
\end{table}
}
Let us consider, for the sake of example, that the voltage follower (very low gain of 1.0)
amplification chracteristics from FS2 and FS6 can be considered as low output from the OPAMP for the application
Let us consider, for the sake of the example, that the voltage follower (very low gain of 1.0)
amplification characteristics from FS2 and FS6 can be considered as low output from the OPAMP for the application
in hand (say milli-volt signal amplification).
For this amplifier configuration we have three failure modes; $AMPHigh, AMPLow, LowPass$.%see figure~\ref{fig:fgampb}.
@ -1132,18 +1139,18 @@ We evaluate the FMMD method using the criteria in section \ref{fmmdreq}.
Table \ref{tbl:comparison} compares the current methodologies and FMMD using these criteria.
{ %\small
\begin{itemize}
\item{State Explosion is reduced,}
\item{State explosion is reduced,}
%State Explosion is reduced,
because small collections of components are dealt with in functional groups
because small collections of components are dealt within functional groups
which are used to create derived components which are then used in an hierarchical manner.
\item{All component failure modes must be considered in the model.}
%All component failure modes must be considered in the model.
Since the proposed methodology is bottom-up.
This means that we can ensure/check that all component failure modes are handled.
Since the proposed methodology is bottom-up,
this means that we can ensure/check that all component failure modes are handled.
\item{ It should be straight forward to integrate mechanical, electronic and software models,}
\item{ It should be straightforward to integrate mechanical, electronic and software models,}
%It should be straight forward to integrate mechanical, electronic and software models,
because FMMD models in terms of failure modes only. % we have a generic failure mode entities to model.
%We can describe a mechanical, electrical or software component in terms of its failure modes.
@ -1155,14 +1162,14 @@ using a common notation.
\item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
%It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
The hierarchical nature, taking {\fg}s and deriving components from them, means that
commonly used {\dcs} can be re-used in a design% (for instance self checking digital inputs)
commonly used {\dcs} can be re-used in a design % (for instance self checking digital inputs)
or even in other projects where the same {\dc} is used.
\item{ Formal basis: data should be available to produce mathematical proofs and traceability.}
%It should have a formal basis, data should be available to produce mathematical proofs
%for its results
Because the failure mode model of a system is a hierarchy of {\fg}s and {\dcs}
Because the failure mode model of a system is a hierarchy of {\fg}s and {\dcs},
system level failure modes are traceable back down the fault tree to
component level failure modes.
%
@ -1188,17 +1195,20 @@ to be determined by traversing the DAG from top level events down to their cause
% are built from components performing a given task.
%
\item{ Multiple failure modes (conjunction) may be modelled from the base component level up.}
\item{ Multiple failure modes (conjunction - where more that one failure mode is active)
may be modelled from the base component level up.}
%Multiple failure modes (conjunction) may be modelled from the base component level up.
By breaking the problem of failure mode analysis into small stages
and building a hierarchy, the problems associated with the cross products of
all failure modes within a system are reduced.
and building a hierarchy, the problems associated with needing to
analyze all possible combinations of base level components
within a system are reduced.
% by an exponential order.
This is because the multiple failure modes considered
within {\fgs} have fewer failure modes to consider
at each FMMD stage.
Where appropriate, multiple simultaneous failures can be modelled by
introducing {\fc} %test~cases
introducing {\fcs} %test~cases
where the conjunction of failure modes is considered.
\end{itemize}
}
@ -1239,7 +1249,7 @@ where the conjunction of failure modes is considered.
%This new approach is called
Failure Mode Modular De-Composition (FMMD) is designed
to be a more rigorous and `data~complete' model than
the current four approaches
the current four approaches.
%
That is,
from an FMMD model, we should be able to
@ -1247,6 +1257,10 @@ derive outline models that the other four methodologies would have been
able to create. As this approach is modular, many of the results of
analysed components may be re-used in other projects, so
test efficiency is improved.
%Clearly the more complex the original system is the more benefit,
%i.e. less components and derived components, will be produced from decomposing the
%system into functional groups.
FMMD is based on generic failure modes, so it is not constrained to a
particular field. It can be applied to mechanical, electrical or software domains.
It can therefore be used to analyse systems comprised of electrical,
@ -1255,6 +1269,7 @@ Furthermore the reasoning path is traceable. By being able to trace a
top level event down through derived components, to base component
failure modes, with each step annotated as {\fcs}, the model is easier to maintain.
%\today
%
{ %\tiny %\footnotesize