Put document structure in
This commit is contained in:
parent
8a9b9dbb23
commit
faed2488d9
@ -60,6 +60,8 @@
|
|||||||
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
|
\newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
|
||||||
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
|
\newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
|
||||||
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
|
\newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
|
||||||
|
\newcommand{\fm}{failure~mode}
|
||||||
|
\newcommand{\fms}{failure~modes}
|
||||||
\newcommand{\fg}{functional~group}
|
\newcommand{\fg}{functional~group}
|
||||||
\newcommand{\fgs}{functional~groups}
|
\newcommand{\fgs}{functional~groups}
|
||||||
\newcommand{\dc}{derived~component}
|
\newcommand{\dc}{derived~component}
|
||||||
@ -119,7 +121,7 @@ failure mode of the component or sub-system}}}
|
|||||||
%\nodate
|
%\nodate
|
||||||
\maketitle
|
\maketitle
|
||||||
|
|
||||||
\paragraph{Keywords:} static failure mode modelling safety-critical
|
\paragraph{Keywords:} static failure mode modelling safety-critical software fmea
|
||||||
%\small
|
%\small
|
||||||
|
|
||||||
\abstract{ \em
|
\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.
|
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.
|
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
|
Standards~\cite{en298}~\cite{en61508} that use FMEA
|
||||||
do not specify it for Software, but do specify, good practise,
|
do not specify it for Software, but do specify, good practise,
|
||||||
review processes and language feature constraints.
|
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
|
and
|
||||||
This is a weakness; if software FMEA were possible electro-mechanical-software hybrids could
|
This is a weakness; where FMEA scientifically traces component {\fms}
|
||||||
be modelled.
|
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
|
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.
|
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}
|
\section{Introduction}
|
||||||
{
|
{
|
||||||
This paper describes and appraises four current failure modelling methodologies.
|
This paper describes a modular FMEA process.
|
||||||
Their advantages and deficiencies are discussed and a desirable criteria list
|
Because this process is based on failure modes of components
|
||||||
for an `ideal' static failure mode methodology is developed.
|
it can be applied to electrical and/or mechanical systems.
|
||||||
A proposed
|
The hierarchical structure of software is then examined,
|
||||||
methodology is then described. % and discussed.
|
and then definitions from contract programming are used
|
||||||
A worked example is then presented, using the new methodology, which models the failure mode
|
to define failure modes and failure symptoms in
|
||||||
behaviour of a non-inverting op-amp circuit.
|
software functions.
|
||||||
Using the worked example the new methodology is evaluated.
|
With these definitions we can apply FMEA
|
||||||
Finally the desirable criteria list is presented as a check box table alongside
|
to existing software\footnote{Existing software excluding recursive code, and unstructured non-functional languages}.
|
||||||
four current methodologies.
|
|
||||||
}
|
}
|
||||||
|
|
||||||
\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
|
%\clearpage
|
||||||
\section{Conclusion}
|
\section{Conclusion}
|
||||||
|
|
||||||
|
Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!!
|
||||||
|
|
||||||
|
|
||||||
|
|
||||||
\paragraph{Future work}
|
\paragraph{Future work}
|
||||||
\begin{itemize}
|
\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
|
||||||
\item To build a {\dcs} library of common electrical, mechanical and software models (i.e. a collection of worked example {\dcs}).
|
\item
|
||||||
\item To provide formal generic translations from the constructed model of any given system to the other models.
|
\item
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
%\today
|
%\today
|
||||||
%
|
%
|
||||||
|
Loading…
Reference in New Issue
Block a user