Robin_PHD/papers/software_fmea/software_fmea.tex

%%% OUTLINE

% Software FMEA
% 
% 
% Glaring hole in approvals FMEA is performed on hardware
% and electronics, but with software we only get guidlines ( which mostly consist of constraints!)
% 
% No known method of software failure mode effects analysis--- some work has been done on
% Sofware FTA a top down approach---
% Bottom up approach means all known failure modes must be modelled.
% SIL does not have metric or tools to analyse software for safety,
% it instead applies best practises and constraints on computer language features (i.e.
% in C limited use of pointers  no recursion etc).
% 
% 
% Introduce concept of FMEA
% * bottom up
% * all failure modes for all componnts
% 
% Concept of FMMD
% 
% Look at the structure of software
% * a natural hierarchy
% 
% Software written for  a controlled
% Contract programming
% * describe concept
% * describe how this fits in with failure modes and failure symptoms concepts
% 
% Describe how contract programming represents the failure modes of software
% 
% Now describe how this fits in with the structure of FMMD

 

\documentclass[twocolumn]{article}
%\documentclass[twocolumn,10pt]{report}
\usepackage{graphicx}
\usepackage{fancyhdr}
\usepackage{tikz}
\usepackage{amsfonts,amsmath,amsthm}
\usetikzlibrary{shapes.gates.logic.US,trees,positioning,arrows}
%\input{../style}
\usepackage{ifthen}
\usepackage{lastpage}
\usetikzlibrary{shapes,snakes}
\newcommand{\tickYES}{\checkmark}
\newcommand{\fc}{fault~scenario}
\newcommand{\fcs}{fault~scenarios}
\date{}
%\renewcommand{\encodingdefault}{T1}
%\renewcommand{\rmdefault}{tnr}
%\newboolean{paper}
%\setboolean{paper}{true} % boolvar=true or false

\newcommand{\oc}{\ensuremath{^{o}{C}}}
\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}
\newcommand{\dcs}{derived~components}
\newcommand{\bc}{base~component}
\newcommand{\bcs}{base~components}
\newcommand{\irl}{in real life}
\newcommand{\enc}{\ensuremath{\stackrel{enc}{\longrightarrow}}}
\newcommand{\pin}{\ensuremath{\stackrel{pi}{\longleftrightarrow}}}
%\newcommand{\pic}{\em pure~intersection~chain}
\newcommand{\pic}{\em pair-wise~intersection~chain}
\newcommand{\wrt}{\em with~respect~to} 
\newcommand{\abslevel}{\ensuremath{\Psi}}
\newcommand{\fmmdgloss}{\glossary{name={FMMD},description={Failure Mode Modular De-Composition, a bottom-up methodolgy for incrementally building failure mode models, using a procedure taking functional groups of components and creating derived components representing them, and in turn using the derived components to create higher level functional groups, and so on, that are used to build a failure mode model of a system}}}
\newcommand{\fmodegloss}{\glossary{name={failure mode},description={The way in which a failure occurs. A component or sub-system may fail in a number of ways, and each of these is a 
failure mode of the component or sub-system}}}
\newcommand{\fmeagloss}{\glossary{name={FMEA}, description={Failure Mode and Effects analysis (FMEA) is a process where each potential failure mode within a system, is analysed to determine system level failure modes, and  to then classify them {\wrt} perceived severity}}}
\newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failure within a population (of size N), divided by N over a given time interval}}}
\newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}}
\newcommand{\bcfm}{base~component~failure~mode}
\def\layersep{1.8cm}

\newboolean{pld}
\setboolean{pld}{false} % boolvar=true or false : draw analysis using propositional logic diagrams

\newboolean{dag}
\setboolean{dag}{true} % boolvar=true or false : draw analysis using directed acylic graphs

\setlength{\topmargin}{0in}
\setlength{\headheight}{0in}
\setlength{\headsep}{0in}
\setlength{\textheight}{22cm}
\setlength{\textwidth}{18cm}
\setlength{\oddsidemargin}{0in}
\setlength{\evensidemargin}{0in}
\setlength{\parindent}{0.0in}
\setlength{\parskip}{6pt}

\begin{document}
%\pagestyle{fancy}
%\fancyhf{}
%\fancyhead[LO]{}
%\fancyhead[RE]{\leftmark}

%\cfoot{Page \thepage\ of \pageref{LastPage}}
%\rfoot{\today}
%\lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
%\lhead{Developing a rigorous bottom-up modular static failure modelling methodology}
                                   % numbers at outer edges
\pagenumbering{arabic}                        % Arabic page numbers hereafter
\author{R.Clark$^\star$ \\ % , A.~Fish$^\dagger$ , C.~Garrett$^\dagger$, J.~Howse$^\dagger$  \\     
         $^\star${\em Energy Technology Control, UK. r.clark@energytechnologycontrol.com} \and $^\dagger${\em University of Brighton, UK} 
}

%\title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
\title{Applying FMEA to Software}
%\nodate
\maketitle 

\paragraph{Keywords:} static failure mode modelling safety-critical software fmea
%\small

\abstract{ \em 
%The certification process of safety critical products for European and 
%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), is a is a bottom-up technique that aims to assess the effect all
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 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.
 
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.
}

\section{Introduction}
{
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}.
}
 
\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}
\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  
\item  
\item  
\end{itemize}
%\today
%
{ %\tiny %\footnotesize
\bibliographystyle{plain}
\bibliography{vmgbibliography,mybib}
}

%\today
\end{document}