morning edit, and made Makefile
This commit is contained in:
parent
faed2488d9
commit
ee84cdc9c2
13
papers/software_fmea/Makefile
Normal file
13
papers/software_fmea/Makefile
Normal file
@ -0,0 +1,13 @@
|
||||
|
||||
PNG =
|
||||
|
||||
%.png:%.dia
|
||||
dia -t png $<
|
||||
|
||||
|
||||
all:
|
||||
pdflatex software_fmea
|
||||
acroread software_fmea.pdf
|
||||
|
||||
bib:
|
||||
bibtex software_fmea
|
@ -136,11 +136,12 @@ 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
|
||||
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,
|
||||
review processes and language feature constraints.
|
||||
Software generally, sits on top of most safety critical control systems
|
||||
and
|
||||
|
||||
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.
|
||||
@ -168,14 +169,37 @@ to existing software\footnote{Existing software excluding recursive code, and un
|
||||
|
||||
\section{FMEA Process}
|
||||
|
||||
What FMEA is, briefly variants...
|
||||
|
||||
\section{Modularising FMEA}
|
||||
|
||||
Advantages to modularisation, ref SYS SAFETY 2011 paper,
|
||||
|
||||
\section{Software: How can we apply FMEA}
|
||||
|
||||
If FMEA can be applied to software we can build complete failure models
|
||||
of typical modern safety critical systems.
|
||||
With modular FMEA (FMMD) we have the concepts of failure~modes
|
||||
of components, {\fgs} and symptoms of failure for a functional group.
|
||||
|
||||
A programatic function is very similar to a functional group.
|
||||
It calls other functions, which could be viewed as its `components'.
|
||||
It has outputs which will be used by functiona that may call it.
|
||||
|
||||
However, we need to define a clear concept of failure modes of a function in order to
|
||||
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}[bb]~\cite{misra}[cc] and non recursive~\cite{misra}[aa].
|
||||
Because of this we can assume a direct call tree. Functions call functions
|
||||
from the top down and eventually call the lowest level library or IO
|
||||
functions that interact with hardware/electronics.
|
||||
|
||||
|
||||
\subsection{Contract programming description}
|
||||
|
||||
\subsubsection{Mapping contract pre-condition violations to failure modes}
|
||||
|
Loading…
Reference in New Issue
Block a user