From f2c569bf4b56d57b07d9e31545b4dc54a6d9c85f Mon Sep 17 00:00:00 2001 From: Your Name Date: Tue, 3 Apr 2012 14:42:52 +0100 Subject: [PATCH] working on software fmea paper at lunchtime. --- papers/software_fmea/software_fmea.tex | 79 +++++++++++++------------- submission_thesis/CH2_FMEA/copy.tex | 8 +-- 2 files changed, 43 insertions(+), 44 deletions(-) diff --git a/papers/software_fmea/software_fmea.tex b/papers/software_fmea/software_fmea.tex index efb7352..dabd9c1 100644 --- a/papers/software_fmea/software_fmea.tex +++ b/papers/software_fmea/software_fmea.tex @@ -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{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}. +% \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. +% +% 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 !!!!!!!!!!!!!!!!!!!!!!!! diff --git a/submission_thesis/CH2_FMEA/copy.tex b/submission_thesis/CH2_FMEA/copy.tex index 8b54668..259bbea 100644 --- a/submission_thesis/CH2_FMEA/copy.tex +++ b/submission_thesis/CH2_FMEA/copy.tex @@ -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