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

Put document structure in

Browse Source
This commit is contained in:
Your Name 2012-03-22 14:09:28 +00:00
parent 8a9b9dbb23
commit faed2488d9
1 changed files with 48 additions and 20 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

66
papers/software_fmea/software_fmea.tex
View File

@ -60,6 +60,8 @@
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
\newcommand{\fm}{failure~mode}
\newcommand{\fms}{failure~modes}
\newcommand{\fg}{functional~group}
\newcommand{\fgs}{functional~groups}
\newcommand{\dc}{derived~component}
@ -119,7 +121,7 @@ failure mode of the component or sub-system}}}
%\nodate
\maketitle
\paragraph{Keywords:} static failure mode modelling safety-critical
\paragraph{Keywords:} static failure mode modelling safety-critical software fmea
%\small
\abstract{ \em
@ -133,14 +135,19 @@ component failure modes on a system.
It is used both as a design tool (to determine weakness), and is a requirement of certification of safety critical products.
FMEA has been successfully applied to mechanical, electrical and hybrid electro-mechanical systems.
At present no known technique for Software FMEA exists.
At present no technique for Software FMEA known to the authors exists.
Standards~\cite{en298}~\cite{en61508} that use FMEA
do not specify it for Software, but do specify, good practise,
review processes and language feature constraints.
Software gnerally, sits on top of most safety critical control systems
Software generally, sits on top of most safety critical control systems
and
This is a weakness; if software FMEA were possible electro-mechanical-software hybrids could
be modelled.
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. 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.
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.
@ -148,29 +155,50 @@ and integrate-able with FMEA performed on mechanical and electronic systems.
\section{Introduction}
{
This paper describes and appraises four current failure modelling methodologies.
Their advantages and deficiencies are discussed and a desirable criteria list
for an `ideal' static failure mode methodology is developed.
A proposed
methodology is then described. % and discussed.
A worked example is then presented, using the new methodology, which models the failure mode
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
four current methodologies.
This paper describes a modular FMEA process.
Because this process is based on failure modes of components
it can be applied to electrical and/or mechanical systems.
The hierarchical structure of software is then examined,
and then definitions from contract programming are used
to define failure modes and failure symptoms in
software functions.
With these definitions we can apply FMEA
to existing software\footnote{Existing software excluding recursive code, and unstructured non-functional languages}.
}
\subsection{Evaluation of FMMD}
\section{FMEA Process}
\section{Modularising FMEA}
\section{Software: How can we apply FMEA}
\subsection{Software, a natural hierarchy}
Same as FMMD !
\subsection{Contract programming description}
\subsubsection{Mapping contract pre-condition violations to failure modes}
\subsubsection{Mapping contract post-condition violations to symptoms}
\subsection{Software FMEA}
\subsection{Simple Software Example}
Make up a sensor that can read a value but can fail by being out of range 4-20mA ???
%\clearpage
\section{Conclusion}
Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!!
\paragraph{Future work}
\begin{itemize}
\item To provide bounds on the size of the state space for the application of the methodology to certain classes of systems.
\item To build a {\dcs} library of common electrical, mechanical and software models (i.e. a collection of worked example {\dcs}).
\item To provide formal generic translations from the constructed model of any given system to the other models.
\item
\item
\item
\end{itemize}
%\today
%