Had a good bash at this this afternoon, really ought to get back to finishing chapter 5

papers/software_fmea/Makefile

@@ -1,11 +1,11 @@
 
-PNG = 
+PNG = fmmdh.png
 
 %.png:%.dia
 	dia -t png $<
 
 
-all:
+all: ${PNG}
 	pdflatex software_fmea
 	acroread software_fmea.pdf
 

papers/software_fmea/mybib.bib

@@ -88,6 +88,14 @@
   YEAR =         "1981"
 }
 
+@ARTICLE{syssafe2011,
+  AUTHOR =       "R.Clark,A.Fish,J.Howse,C.Garrett",
+  TITLE =        "Developing a rigorous bottom-up modular static failure modelling
+methodology",
+  JOURNAL =      "IET System Safety 2011",
+  YEAR =         "2011"
+}
+
 @ARTICLE{nasafta,
   AUTHOR =       "NASA",
   TITLE =        "Fault Tree Handbook with Aerospace Applications",
@@ -123,6 +131,13 @@
   YEAR =         "1992"
 }
 
+@BOOK{dbcbe,
+  AUTHOR =       "R. Mitchell",
+  TITLE =        "Design by contract, by Example",
+  PUBLISHER =      "Addison-Wesley ISBN 0-201-63460-0",
+  YEAR =         "2002"
+}
+
 @BOOK{safeware,
   AUTHOR =       "Nancy Leveson",
   TITLE =        "Safeware: System safety and Computers ISBN:  0-201-11972-2",
@@ -319,6 +334,13 @@
   year =         "2002"
 }
 
+@MISC{iec61511,
+  author =       "IEC Standard",
+  title =        "IEC61511:2002 Functional safety - Safety instrumented systems for the process industry sector",
+ howpublished = "International Electrotechnical Commission http://www.iec.ch//",
+  year =         "2003"
+}
+
 @MISC{javaarea,
   author =       "Sun~Micro~Systems",
   title =        "Java Area Operations",

papers/software_fmea/software_fmea.tex

@@ -55,7 +55,7 @@
 %\renewcommand{\rmdefault}{tnr}
 %\newboolean{paper}
 %\setboolean{paper}{true} % boolvar=true or false
-
+\newcommand{\ft}{\ensuremath{4\!\!\rightarrow\!\!20mA} }
 \newcommand{\oc}{\ensuremath{^{o}{C}}}
 \newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
 \newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
@@ -121,6 +121,7 @@ failure mode of the component or sub-system}}}
 %\nodate
 \maketitle 
  
+
 \paragraph{Keywords:} static failure mode modelling safety-critical software fmea
 %\small
 
@@ -146,8 +147,9 @@ 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
+be modelled; and would thus be a {\em complete} failure mode model. 
-up through the electronics and then through the controlling software.
+%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 
@@ -156,7 +158,8 @@ and integrate-able with FMEA performed on mechanical and electronic systems.
 
 \section{Introduction}
 {
-This paper describes a modular FMEA process.
+This paper describes a modular FMEA process that can be applied to software.
+This modular variant of FMEA is called Failure Mode Modular de-composition (FMMD).
 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,
@@ -169,7 +172,32 @@ to existing software\footnote{Existing software excluding recursive code, and un
  
 \section{FMEA Process}
 
-What FMEA is, briefly variants...
+%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
+and determining what system level failure modes could be caused.
+
+Several variants of FMEA exist, 
+traditional FMEA being a associated with the manufacturing industry, with the aims of prioritising
+the failures to fix in order of cost. 
+
+Deisgn FMEA (DFMEA) is FMEA applied at the design or approvals stage
+where the aim is to ensure single component failures cannot cause unacceptable system level events.
+
+Failure Mode effect Criticality Analysis (FMECA)  is applied to determine the most potentially dangerous or damaging
+failure modes to fix.
+ 
+
+Failure Mode Effects and Diagnostics Analysis, is FMEA peformed to
+determine a statistical level of safety.
+This is associated with SIL classification levels~\cite{en61508}~\cite{en61511}.
+
+FMMD is a modularisation of FMEA and can produce failure~mode models that can be used in
+all the above variants of FMEA. 
+
+
+
 
 \section{Modularising FMEA}
 
@@ -177,15 +205,16 @@ In outline, in order to modularise FMEA, we must create small modules form the b
 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 all its components.
+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}
+When we have its failure mode behaviour, or the symptoms of failure from the perspective of the {\fg}.
-we can treat it as a {\dc}.
+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{Modulaeising FMEA: Creating a fault hierarchy.}
+\paragraph{Modularising FMEA: Creating a fault hierarchy.}
 
 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 
@@ -202,7 +231,7 @@ A {\fg} is a collection of components that perform some simple task or function.
 In order to determine how a  {\fg} can fail,
 we need to consider all failure modes of its components.
 %
-By analysing the fault behavior of a `{\fg}' with respect to all its components failure modes,
+By analysing the fault behaviour of a `{\fg}' with respect to all its components failure modes,
 we can determine its symptoms of failure.
 %In fact we can call these
 %the symptoms of failure for the {\fg}.
@@ -227,15 +256,35 @@ 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} (called say AMP1) which has a {\em known set of failure modes} (i.e. its symptoms).
+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}.
+Using this diagram we can follow the creation of the hierarcy in 
+a theoretical system.
+There are three functional groups comprised of 
+{\bcs}. These are analysed individually using FMEA.
+That is to say their component failure modes are examined, and the 
+the ways in which the {\fgs} fail; its symptoms of failure are determined.
+The `$\bowtie$' function is now applied to create {\dcs}.
+These are shown in  figure~\ref{fig:fmmdh} above the {\fgs}.
+Now that we have {\dcs} we can use them to form a higher level functional group.
+We apply the same FMEA process to this and can derive a top level
+derived component (which has the system---or top---level failure modes).
 
-DIAGRAM of FMMD Hierarchy.
+\begin{figure}
+ \centering
+ \includegraphics[width=200pt]{./fmmdh.png}
+ % fmmdh.png: 365x405 pixel, 72dpi, 12.88x14.29 cm, bb=0 0 365 405
+ \caption{FMMD Hierarchy}
+ \label{fig:fmmdh}
+\end{figure}
 
 Note the diagram of the FMMD hierarchy is very similar to a simple non-recursive 
 programmatic function call tree.
@@ -248,7 +297,7 @@ 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 calls other functions, and uses data sources, which could be viewed as its `components'.
 It has outputs which will be used by functions that may call it.
 
 However, we need to define a clear concept of failure modes of a function in order to
@@ -259,7 +308,7 @@ map FMMD to software.
 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].
+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
 from the top down and eventually call the lowest level library or IO
 functions that interact with hardware/electronics.
@@ -267,21 +316,77 @@ functions that interact with hardware/electronics.
 
 \subsection{Contract programming description}
 
-Contract programming is a discipline for building software functions in a controlled
+Contract programming is a discipline~\cite{dbcbe} for building software functions in a controlled
 and traceable way. Each function is subject to pre-conditions (constraints on its inputs),
 post-conditions (constraints on its outputs) and function wide invariants (rules).
 
 
 \subsubsection{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
+to operate successfully.
+
+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}
 
+A post condition is a definition of correct behaviour by a function.
+This could be an action performed or an output value.
+
+A violated post condition is a symptom of failure of a function.
+
 \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 ???
+
-Thus our sensor can be seen as working corectly if its voltage is between
+Consider a function that reads a {\ft} input, and returns a value between 0 and 999
-0.9 and 4.4, but outside that range it is considered to have failed.
+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.
+Let us define any value outside the 4mA to 20mA range as an error condition.
+As a voltage, we use ohms law~\cite{aoe} to determine the voltage ranges: $V=IR$, $0.004A * \ohms{220} = 0.88V$
+and $0.020A * \ohms{220} = 4.4V$. Our acceptable voltage range is therefore $V >= 0.88 \wedge V<= 4.4$. 
+This voltage range forms our input requirement.
+We can now examine software function. For the purpose of example the `C' programming language is used.
+We assume a function {\em read\_ADC()} which returns a double precision 
+value which holds the voltage read.
+{\vbox{
+\footnotesize
+\begin{verbatim}
+/* Software function to read 4mA to 20mA input */
+/* returns a value from 0-999 proportional     */
+/* to the current input.                       */
+int  read_4_20_input ( int * value ) {
+  double input_volts;
+  int error_flag;
+
+  /* require: input from ADC to be 
+              between 0.88 and 4.4 volts */
+
+
+  input_volts = read_ADC(INPUT_4_20_mA);
+
+  if ( input_volts < 0.88 || input_volts > 4.4 ) {
+    error_flag = 1; /* Error flag set to TRUE */
+  }
+  else {
+    *value = (input_volts - 0.88) * ( 4.4 - 0.88 ) * 999.0;
+    error_flag = 0; /* indicate current input in range */
+  }
+
+  /* ensure: value is proportional (0-999) to the 
+             4 to 20mA input                      */
+
+  return error_flag;
+}
+\end{verbatim}
+}
+}
 
 %\clearpage
 \section{Conclusion}