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

fixed some typos, really needs time to get the story flow into it a

Browse Source 
little better and a better conclusion
This commit is contained in:
Robin Clark 2015-03-24 07:03:31 +00:00
parent 07c5788e1e
commit 9283bdccba
1 changed files with 108 additions and 96 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

204
papers/JOURNAL_fmea_sw_hw/sw_hw_fmea.tex
View File

@ -128,7 +128,7 @@ other international standards often demand environmental stress,
endurance and Electro Magnetic Compatibility (EMC) testing. Theoretical, or 'static testing',
is often also required.
Failure Mode Effects Analysis (FMEA)~\cite{iec60812}, is a bottom-up technique that aims to assess the effect all
Failure Mode Effects Analysis (FMEA)~\cite{iec60812}, is a bottom-up static testing technique that aims to assess the effect all
component failure modes on a system.
%
It is used both as a design tool (to determine weaknesses), and as a requirement of certification of safety critical products.
@ -139,7 +139,7 @@ This paper discusses the benefits and drawbacks of current
FMEA techniques and then proposes a modular FMEA methodology,
Failure Mode Modular De-Composition (FMMD)~\cite{clark}
that has the advantages modularity, traceable failure modes throughout the model
hierarchy, increase in test efficiency
hierarchy, an increase in test efficiency
and has
the ability to model integrated hardware and software systems.
@ -159,7 +159,9 @@ the ability to model integrated hardware and software systems.
% reaches conclusions about the effectiveness and failure mode
% coverage of the combined FMEA techniques.
A small, but complete embedded system, worked example is presented to show FMMD applied to an
To demonstrate FMMDA a small, but complete embedded system
(including both software and hardware),
worked example is presented to show FMMD applied to an
integrated electronics/software system.
%, the industry standard
%{\ft} signalling loop.
@ -194,8 +196,9 @@ Currently standards that demand FMEA investigations for hardware(HFMEA) (e.g. E
do not specify it for software but instead essentially just specify good practise,
i.e. review processes and language feature constraints.
%
That is to say there id no formal framework for following
That is to say FMEA has no formal framework for following
failure modes from low level hardware elements through into the software models.
%
This is a weakness.
%
@ -343,8 +346,10 @@ a metric for for evaluating FMEA is defined.
%
This count of checks is defined as `reasoning~distance' ---or in other words is --- the number of stages of logic and reasoning used
in {\fm} analysis to map a failure cause to its potential outcomes; counted
by the number of {\fm} to other component analysis stages made.
in {\fm} analysis to map a failure cause to its potential outcome;
counted by the number of %{\fm} to
other components in the system.
%analysis stages made.
%
%The basic FMEA example in section~\ref{basicfmea}
%considered one {\fm} against some of the components in the milli-volt reader.
@ -360,9 +365,9 @@ No current FMEA variant gives guidelines for the components that should
be included to analyse a {\fm} in a system.
%
Were a {\fm} examined against all the other components in a system
this would give a maximum reasoning distance.
this gives a maximum reasoning distance.
%
This is termed the exhaustive FMEA (XFMEA) case for a single {\fm}.
This is termed the exhaustive FMEA (XFMEA). % case for a single {\fm}.
%does not
% The exhaustive~reasoning~distance would be
% the sum of the number of failure modes, against all other components
@ -373,19 +378,24 @@ the number of failure modes it has by the number of remaining components
in the system.
%
The exhaustive reasoning~distance for a system would be the
the sum of these multiplications for all the components it contains.
the sum of these multiplications for all its components. % it contains.
%
If a small system were to have say 100 components, with three failure modes per component, this
would give an exhaustive reasoning distance---for single failure analysis---of $3 \times 100 \times 99$.
would give an exhaustive reasoning distance. % ---for single failure analysis---of $3 \times 100 \times 99$.
That means to for each {\fm} of every component, $3$, a check would have to be made
against 99 other components. There are 100 components in this hypothetical example so
for single failure analysis this means $3 \times 100 \times 99$ checks.
%
The discussion on reasoning distance provides a metric to examine
the state explosion problems associated with FMEA ( and other forward search failure investigation
This concept of `reasoning~distance' provides a metric to examine
the state explosion problems associated with FMEA (and other forward search failure investigation
methodologies).
%
%\fmmdglossSTATEEX
%
It is apparent that the shorter the reasoning distance, the more precisely theoretical examination
can determine failure symptoms.
A high reasoning distance, because it is a manual process performed by experperts, is both
expensive in terms of time and money.
It is apparent also that the shorter the reasoning distance, the more precisely theoretical examination
can determine failure symptoms. A shorter reasoning distance therefore implies a higher quality of safety analysis.
%
For instance for a very simple small circuit, a better understanding of failure effects is expected,
than for a very large system where there are more variables and potential {\fm} interactions.
@ -394,24 +404,24 @@ than for a very large system where there are more variables and potential {\fm}
%failure analysis is the more modules and components are involved
% cite for forward and backward search related to safety critical software
%{sfmeaforwardbackward}
\subsection{FMEA and the State Explosion Problem}
%\subsection{FMEA and the State Explosion Problem}
\label{sec:xfmea}
\paragraph{Problem of which components to check for a given {\bc} {\fm}.}
%\fmmdglossSTATEEX
%
FMEA for safety critical certification (i.e. for EN298 and EN61508)~\cite{en298,en61508} has to be applied
to all known failure modes of all components within a system.
%
Each one of these, in a typical report, would be one line of a spreadsheet entry.
%
FMEA does not define or specify the scope of the investigation for each component failure mode.
%
For instance should the signal path be followed, with all components encountered along that, or should the scope be wider?
%
%If we wethe effect of a component {\fm} against all other components
%in a system, this could be said to be exhaustive analysis.
% \paragraph{Problem of which components to check for a given {\bc} {\fm}.}
% %\fmmdglossSTATEEX
% %
% FMEA for safety critical certification (i.e. for EN298 and EN61508)~\cite{en298,en61508} has to be applied
% to all known failure modes of all components within a system.
% %
% Each one of these, in a typical report, would be one line of a spreadsheet entry.
% %
% FMEA does not define or specify the scope of the investigation for each component failure mode.
% %
% For instance should the signal path be followed, with all components encountered along that, or should the scope be wider?
% %
% %If we wethe effect of a component {\fm} against all other components
% %in a system, this could be said to be exhaustive analysis.
\paragraph{Exhaustive Single Failure FMEA.}
\paragraph{Exhaustive Single Failure FMEA Order equation.}
%\fmmdglossXFMEA
%
To perform XFMEA, every possible interaction
@ -433,9 +443,9 @@ $f$ is the number of failure modes per component:
This means an order of $O(N^2)$ checks to perform
to undertake XFMEA for single failures.
%
Even small systems have typically
100 components, and they typically have 3 or more failure modes each, which would give
$100 \times 99 \times 3 = 29,700 $ as a reasoning~distance.
%Even small systems have typically
%100 components, and they typically have 3 or more failure modes each, which would give
The hypothetical example described above gives $100 \times 99 \times 3 = 29,700 $ as a reasoning~distance.
%
%\fmmdglossSTATEEX
\paragraph{Exhaustive FMEA and double failure scenarios.}
@ -443,7 +453,7 @@ $100 \times 99 \times 3 = 29,700 $ as a reasoning~distance.
%\paragraph{Exhaustive Double Failure FMEA}
For looking at potential double failure
scenarios\footnote{Certain double failure scenarios are already legal
requirements---The European Gas burner standard (EN298:2003~\cite{en298})---demands the checking of
requirements---The European Gas burner standard (EN298:2003~\cite{en298}) for instance---demands the checking of
double failure scenarios (for burner lock-out scenarios).}
%
(two components failing within a given time frame) and the order becomes $O(N^3)$.
@ -529,8 +539,10 @@ Performing failure analysis using the basic component single failure modes to
system failure mapping, would be very difficult: this would require expert knowledge
of the design behaviour and component types used in each module.
%
Because modern systems have become more complex and now include software elements modularity
of some form, has become necessary to break down the state explosion problems associated with FMEA.
Because modern systems have become more complex and now include software elements,
modularity
of some form (breaking the problem down into smaller sections),
has become necessary to break down the state explosion problems associated with FMEA.
%
Some modular techniques are starting to be formalised, and are described below.
@ -718,7 +730,7 @@ in an improved FMEA methodology,
\item re-usable i.e. it should be possible to re-use analysis,
\item possibility to analyse simultaneous/multiple failures,
%\item one to one mapping from {\bc} {\fms} to system level failures (see section~\ref{sec:onetoone}),
\item modular --- i.e. usable in a distributed system.
\item able to model a system built with bought in sub-systems --- i.e. usable in a distributed system.
% \item
\end{itemize}
@ -793,10 +805,10 @@ An advantage of performing FMEA in this modular way, is that the
of the reasoning distance is greatly reduced for the overall project.
This addresses the state explosion problem of XFMEA.
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%FFT%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
In the field of digital signal processing there is an algorithm that revolutionised
\footnote{In the field of digital signal processing there is an algorithm that revolutionised
access to frequency analysis of digital samples called the Fast Fourier Transform (FFT)~\cite{fftoriginal}.
This took the Discrete Fourier Transform (DFT), and applied de-composition to its
mesh of (often repeated) complex number calculations~\cite{fpodsadsp}[Ch.8].
mesh of (often repeated) complex number calculations~\cite{fpodsadsp}[Ch.8].}
%
By doing this it broke the computing order of complexity down from having a polynomial %n exponential
%order
@ -1466,71 +1478,71 @@ and ram complement checking can be applied.
%system failure, something difficult to prove with current FMEA techniques.
\subsection{Hardware: Sensors, actuators and indication}
%\subsection{Hardware: Sensors, actuators and indication}
\subsection{Simple Software Example}
%\subsection{Simple Software Example}
\subsection{Software FMEA - The software/hardware interface}
%\subsection{Software FMEA - The software/hardware interface}
\section{Conclusion}
%
% This paper has picked a very simple example %(the industry standard {\ft}
% %input circuit and software)
% to demonstrate
% SFMEA and HFMEA methodologies used to describe a failure mode model.
% %Even a modest system would be far too large to analyse in conference paper
% %and this
% %
% %The {\dc} representing the {\ft} reader
% %shows that by taking a
% %modular approach for FMEA, i.e. FMMD, we can integrate
% Our model is described by four FMEA reports; and these % we can model the failure mode behaviour from
% model the system from several failure mode perspectives.
% %
% With traditional FMEA methods the reasoning~distance is large, because
% it stretches from the component failure mode to the top---or---system level failure.
% %
% With these four analysis reports
% we do not have stages along the `reasoning~path' linking the failure modes from the
% electronics to those in the software.
% %Software is often written `defensively' but t
% %Each {\fg} to {\dc} transition represents a
% %reasoning stage.
% %
% %
% %For this reason applying traditional FMEA to software stretches
% %the reasoning distance even further.
% %
% In fact many these reasoning paths overlap---or even by-pass one another---
% it is very difficult to gauge cause and effect.
% For instance, hardware failures are not analysed in the context of how they will
% be handled (or missed) by the software.
% %
% System outputs commanded from software may not take into account particular
% hardware limitations etc.
%
% The interface FMEA does serve to provide a useful
% check-list to ensure data and synchronisation conventions used by the hardware
% and software are not mismatched. However, the fact it is perceived as required
% highlights the the miss-matches possible between the two types of analysis
% which could run deeper than the mere interface level.
%
%
% However, while these techniques ensure that the software and hardware is
% viewed and analysed from several perspectives, it cannot be termed a homogeneous
% failure mode model.
% % For instance
% % were the ADC to have a small value error, say adding
% % a small percentage onto the value, we would be unable to
% % detect this under the analysis conditions for this model, or
% % be able to pinpoint it.
% %
%
% Need wishlist ticks and solved problems here.
This paper has picked a very simple example (the industry standard {\ft}
input circuit and software)
to demonstrate
SFMEA and HFMEA methodologies used to describe a failure mode model.
Even a modest system would be far too large to analyse in conference paper
and this
The {\dc} representing the {\ft} reader
shows that by taking a
modular approach for FMEA, i.e. FMMD, we can integrate
Our model is described by four FMEA reports; and these % we can model the failure mode behaviour from
model the system from several failure mode perspectives.
With traditional FMEA methods the reasoning~distance is large, because
it stretches from the component failure mode to the top---or---system level failure.
With these four analysis reports
we do not have stages along the `reasoning~path' linking the failure modes from the
electronics to those in the software.
Software is often written `defensively' but t
Each {\fg} to {\dc} transition represents a
reasoning stage.
For this reason applying traditional FMEA to software stretches
the reasoning distance even further.
In fact many these reasoning paths overlap---or even by-pass one another---
it is very difficult to gauge cause and effect.
For instance, hardware failures are not analysed in the context of how they will
be handled (or missed) by the software.
System outputs commanded from software may not take into account particular
hardware limitations etc.
The interface FMEA does serve to provide a useful
check-list to ensure data and synchronisation conventions used by the hardware
and software are not mismatched. However, the fact it is perceived as required
highlights the the miss-matches possible between the two types of analysis
which could run deeper than the mere interface level.
However, while these techniques ensure that the software and hardware is
viewed and analysed from several perspectives, it cannot be termed a homogeneous
failure mode model.
For instance
were the ADC to have a small value error, say adding
a small percentage onto the value, we would be unable to
detect this under the analysis conditions for this model, or
be able to pinpoint it.
Need wishlist ticks and solved problems here.
{
\footnotesize