From 46c0c9980ad9356a0644b374245fe52e48920193 Mon Sep 17 00:00:00 2001 From: "Robin P. Clark" Date: Fri, 13 Jul 2012 09:05:28 +0100 Subject: [PATCH] AF comments first two pages --- .../fmmd_software_hardware/software_fmmd.tex | 39 ++++++++++--------- 1 file changed, 21 insertions(+), 18 deletions(-) diff --git a/papers/fmmd_software_hardware/software_fmmd.tex b/papers/fmmd_software_hardware/software_fmmd.tex index cd4452a..8a5b4e9 100644 --- a/papers/fmmd_software_hardware/software_fmmd.tex +++ b/papers/fmmd_software_hardware/software_fmmd.tex @@ -135,7 +135,7 @@ failure mode of the component or sub-system}}} %\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$ \\ +\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} } @@ -145,7 +145,7 @@ failure mode of the component or sub-system}}} \maketitle -\paragraph{Keywords:} static failure mode modelling safety-critical software fmea +\paragraph{Keywords:} static failure mode modelling; safety-critical; software fmea %\small \abstract{ % \em @@ -181,7 +181,7 @@ Software generally sits on top of most modern safety critical control systems and defines its most important system wide behaviour and communications. % Currently standards that demand FMEA for hardware (e.g. EN298, EN61508), -do not specify it for software, but instead specify, good practise, +do not specify it for software, but instead specify good practise, review processes and language feature constraints. % This is a weakness. @@ -192,7 +192,7 @@ to resultant system failures, software has been left in a non-analytical limbo of best practises and constraints. % % If software and hardware integrated FMEA were possible, electro-mechanical-software hybrids could -be modelled, and could thus be `complete' failure mode models. +be modelled, and so we could consider `complete' failure mode models. % Presently FMEA, stops at the glass ceiling of the computer program: FMMD seeks to address this, and offers additional test efficiency benefits. @@ -216,7 +216,7 @@ software functions. % With these definitions we can apply the FMMD modular form of FMEA to existing software\footnote{Existing software excluding recursive~\cite{misra}[16.2] code, -and unstructured non-functional languages}. +and unstructured non-functional language.}. } \section{FMEA Background} @@ -224,7 +224,8 @@ and unstructured non-functional languages}. %What FMEA is, briefly variants... Failure Mode Effects Analysis is the process of taking -component failure modes, and by reasoning, tracing their 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. % FMEA dates from the 1940s where simple electro-mechanical systems were the norm. @@ -251,7 +252,7 @@ is a cause for criticism~\cite{safeware}[Ch.12]. %FMMD is a modularisation of FMEA and can produce failure~mode models that can be used in %all the above variants of FMEA. -\subsection{Current work on Software FMEA} +\paragraph{Current work on Software FMEA} SFMEA usually does not seek to integrate hardware and software models, but to perform @@ -261,7 +262,7 @@ Work has been performed using databases to track the relationships between variables and system failure modes~\cite{procsfmeadb}, to %work has been performed to introduce automation into the FMEA process~\cite{appswfmea} and to provide code analysis -automation~\cite{modelsfmea}. Although the SFMEA and hardware FMEAs are performed separately +automation~\cite{modelsfmea}. Although the SFMEA and hardware FMEAs are performed separately, some schools of thought aim for Fault Tree Analysis (FTA)~\cite{nasafta,nucfta} (top down - deductive) and FMEA (bottom-up inductive) to be performed on the same system to provide insight into the @@ -299,9 +300,11 @@ of failure mode behaviour for the entire system. % With higher level modules, we can reach the level in which the software resides. % -For instance, to read a voltage into software via an ADC we rely on an electronic sub-system +For instance, to read a voltage into software via an Analogue to Digital Converter (ADC) we rely on an electronic sub-system that conditions the input signal and then routes it through a multiplexer to the ADC. % +% up to here committed AF comments 12JUL2012 +% We could easily consider this electronics a `module', and with a failure mode model for it, modelling the software to hardware interface becomes far simpler. @@ -599,7 +602,7 @@ We can now examine a software function that performs a conversion from the volta a per~mil representation of the {\ft} input current. % For the purpose of example the `C' programming language~\cite{DBLP:books/ph/KernighanR88} is -used\footnote{ C coding examples use the Misra~\cite{misra} and SIL 3 recommended language constraints~\cite{en61508}.}. +used\footnote{ C coding examples use the Misra~\cite{misra} and SIL-3 recommended language constraints~\cite{en61508}.}. We initially assume a function \textbf{read\_ADC} which returns a floating point %double precision value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}). @@ -788,22 +791,22 @@ With these failure modes, we can analyse our first functional group, see table~\ \textbf{Scenario} & \textbf{effect} & \textbf{ADC } \\ \hline \hline 1: $R_{OPEN}$ & resistor open, & $HIGH$ \\ - & voltage on pin high & \\ \hline + & voltage on pin high & \\ \hline - 2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\ - & voltage on pin low & \\ \hline + 2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\ + & voltage on pin low & \\ \hline 3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\ - & fixed value & \\ \hline + & fixed value & \\ \hline 4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\ - & wrong channel & \\ \hline + & wrong channel & \\ \hline - 5: $ADC_{LOW}$ & output low & $LOW$ \\ - 6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline + 5: $ADC_{LOW}$ & output low & $LOW$ \\ + 6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline \hline @@ -853,7 +856,7 @@ by stating: $ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $ As we have a failure mode model for our function, we can now use it in conjunction with -with the ADC hardware {\dc} CMATV, to form a {\fg} $G_2$, where $G_2 =\{ CMSTV, Read\_ADC \}$. +the ADC hardware {\dc} CMATV, to form a {\fg} $G_2$, where $G_2 =\{ CMSTV, Read\_ADC \}$. % We now analyse this hardware/software combined {\fg}.