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

working on software fmea

Browse Source 
paper at lunchtime.
This commit is contained in:
Your Name 2012-04-03 14:42:52 +01:00
parent 005b33de08
commit f2c569bf4b
2 changed files with 43 additions and 44 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

77
papers/software_fmea/software_fmea.tex
View File

@ -40,6 +40,7 @@
%\documentclass[twocolumn,10pt]{report}
\usepackage{graphicx}
\usepackage{fancyhdr}
%\usepackage{wassysym}
\usepackage{tikz}
\usepackage{amsfonts,amsmath,amsthm}
\usetikzlibrary{shapes.gates.logic.US,trees,positioning,arrows}
@ -56,6 +57,7 @@
%\newboolean{paper}
%\setboolean{paper}{true} % boolvar=true or false
\newcommand{\ft}{\ensuremath{4\!\!\rightarrow\!\!20mA} }
\newcommand{\permil}{\ensuremath{{ }^0/_{00}}}
\newcommand{\oc}{\ensuremath{^{o}{C}}}
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
@ -137,7 +139,7 @@ It is used both as a design tool (to determine weakness), and is a requirement o
FMEA has been successfully applied to mechanical, electrical and hybrid electro-mechanical systems.
At present no technique for Software FMEA known to the authors exists.
Software generally, sits on top of most safety critical control systems
Software generally, sits on top of most modern safety critical control systems
and defines its most important system wide behaviour and communications.
Standards~\cite{en298}~\cite{en61508} that use FMEA
do not specify it for Software, but do specify, good practise,
@ -147,10 +149,10 @@ This is a weakness; where FMEA scientifically traces component {\fms}
to resultant system failures; software has been left in a non-analytical
limbo of best practises and constraints.
If software FMEA were possible electro-mechanical-software hybrids could
be modelled; and would thus be a {\em complete} failure mode model.
be modelled; and could thus be `complete' failure mode models.
%Failure modes in components in say a sensor, could be traced
%up through the electronics and then through the controlling software.
Present FMEA stops at the glass ceiling of the computer program.
Presently FMEA, stops at the glass ceiling of the computer program.
This paper presents an FMEA methodology which can be applied to software, and is compatible
and integrate-able with FMEA performed on mechanical and electronic systems.
@ -175,7 +177,7 @@ to existing software\footnote{Existing software excluding recursive code, and un
%What FMEA is, briefly variants...
Failure Mode effects Analysis is the process of taking
component failure modes, and by reasoning, tracing its effects through a system
component failure modes, and by reasoning, tracing their effects through a system
and determining what system level failure modes could be caused.
Several variants of FMEA exist,
@ -204,20 +206,19 @@ all the above variants of FMEA.
In outline, in order to modularise FMEA, we must create small modules form the bottom-up.
We can do this by taking collections of base~components that
perform (ideally) a simple and well defined task.
We can call these {\fgs}.
We can then analyse the failure mode behaviour of a {\fg}
using all the failure modes of its components.
When we have its failure mode behaviour, or the symptoms of failure from the perspective of the {\fg}.
We now treat the {\fg} as a {\dc}; where the failure modes of the {\dc} are the symptoms of failure of the {\fg}.
We can call these {\fgs}. We can then analyse the failure mode behaviour of a {\fg}
using all the failure modes of all its components.
When we have its failure mode behaviour, or the symptoms of failure from the perspective of the {\fg},
we now treat the {\fg} as a {\dc}; where the failure modes of the {\dc} are the symptoms of failure of the {\fg}.
We can now use {\dcs} to build higher level {\fgs} until we have a complete hierarchical model
of the failure mode behaviour of a system. An example of this process, applied to an inverting op-amp configuration
is given in~\cite{syssafe2011}.
\paragraph{Modularising FMEA: Creating a fault hierarchy.}
\paragraph{FMMD, the process.}
The main concept of Failure Mode Modular Discrimination (FMMD) is to build a hierarchy of failure behaviour from the {\bc}
level up to the top, or system level, with analysis stages between each
The main aim of Failure Mode Modular Discrimination (FMMD) is to build a hierarchy of failure behaviour from the {\bc}
level up to the top, or system level, with analysis stages, {\fgs} %and corresponding {\dcs}
, between each
transition to a higher level in the hierarchy.
@ -243,26 +244,26 @@ In other words we have taken a {\fg}, and analysed how
\textbf{it} can fail according to the failure modes of its components, and then
determined the {\fg} failure modes.
\paragraph{Creating a derived component.}
We create a new `{\dc}' which has
the failure symptoms of the {\fg} from which it was derived, as its set of failure modes.
This new {\dc} is at a higher `failure~mode~abstraction~level' than {\bcs}.
% \paragraph{Creating a derived component.}
% We create a new `{\dc}' which has
% the failure symptoms of the {\fg} from which it was derived, as its set of failure modes.
% This new {\dc} is at a higher `failure~mode~abstraction~level' than {\bcs}.
% %
% \paragraph{An example of a {\dc}.}
% To give an example of this, we could look at the components that
% form, say an amplifier. We look at how all the components within it
% could fail and how that would affect the amplifier.
% %
% The ways in which the amplifier can be affected are its symptoms.
% %
% When we have determined the symptoms, we can
% create a {\dc} which has a {\em known set of failure modes} (i.e. its symptoms).
% We can now treat $AMP1$ as a pre-analysed, higher level component.
% The amplifier is an abstract concept, in terms of the components.
%
\paragraph{An example of a {\dc}.}
To give an example of this, we could look at the components that
form, say an amplifier. We look at how all the components within it
could fail and how that would affect the amplifier.
%
The ways in which the amplifier can be affected are its symptoms.
%
When we have determined the symptoms, we can
create a {\dc} which has a {\em known set of failure modes} (i.e. its symptoms).
We can now treat $AMP1$ as a pre-analysed, higher level component.
The amplifier is an abstract concept, in terms of the components.
To a make an `amplifier' we have to connect a a group of components
in a specific configuration. This specific configuration corresponds to
a {\fg}. Our use of it as a building block corresponds to a {\dc}.
% To a make an `amplifier' we have to connect a a group of components
% in a specific configuration. This specific configuration corresponds to
% a {\fg}. Our use of it as a building block corresponds to a {\dc}.
We can use the symbol $\bowtie$ to represent the creation of a derived component
from a {\fg}. We show an FMMD hierarchy in figure~\ref{fig:fmmdh}.
@ -305,8 +306,6 @@ map FMMD to software.
\subsection{Software, a natural hierarchy}
Same as FMMD !
Software written for safety critical systems is usually constrained to
be modular~\cite{en61508}[3]~\cite{misra}[cc] and non recursive~\cite{misra}[aa]~\cite{iec61511}.
Because of this we can assume a direct call tree. Functions call functions
@ -321,7 +320,7 @@ and traceable way. Each function is subject to pre-conditions (constraints on it
post-conditions (constraints on its outputs) and function wide invariants (rules).
\subsubsection{Mapping contract pre-condition violations to failure modes}
\paragraph{Mapping contract pre-condition violations to failure modes}
A precondition, or requirement for a contract software function
defines the correct ranges of input conditions for the function
@ -331,7 +330,7 @@ For a software function, a violation of a pre-condition is
in effect a failure mode of one of its components.
\subsubsection{Mapping contract post-condition violations to symptoms}
\paragraph{Mapping contract post-condition violations to symptoms}
A post condition is a definition of correct behaviour by a function.
This could be an action performed or an output value.
@ -343,8 +342,8 @@ A violated post condition is a symptom of failure of a function.
\subsection{Simple Software Example}
Consider a function that reads a {\ft} input, and returns a value between 0 and 999
representing the current detected with an error indication flag.
Consider a function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$)
representing the current detected with an error indication flag .
Let us assume the {\ft} detection is via a \ohms{220} resistor., and that we read a voltage
from an ADC into the software.
@ -391,7 +390,7 @@ int read_4_20_input ( int * value ) {
%\clearpage
\section{Conclusion}
Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!!
%Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!!

8
submission_thesis/CH2_FMEA/copy.tex
View File

@ -2,12 +2,12 @@
EN61508:6\cite{en61508}[B.6.6]
describes FMEA as
describes FMEA as:
\begin{quotation}
To analyse a system design, by examining all possible sources of failure
"To analyse a system design, by examining all possible sources of failure
of a system's components and determining the effects of these failures
on the behaviour and safety of the system.
\end{quotation}
on the behaviour and safety of the system."
\end{quotation}.
sample text
sample text