From 4e1012d9fa4cade954ade355dc3893aba43839cd Mon Sep 17 00:00:00 2001 From: robin Date: Tue, 10 Apr 2012 20:26:54 +0100 Subject: [PATCH] evening edit of paper waiting for supervisors to REPLY --- papers/software_fmea/hd.dia | Bin 2203 -> 2335 bytes papers/software_fmea/software_fmea.tex | 105 ++++++++++++++----------- 2 files changed, 61 insertions(+), 44 deletions(-) diff --git a/papers/software_fmea/hd.dia b/papers/software_fmea/hd.dia index 3e38609f60c1859ed5f96195c0b9e49064320f97..5f7b599677112e978796168e0336d8fb10a30874 100644 GIT binary patch literal 2335 zcmV+)3E=i0iwFP!000021MOXHZ`;Tb{+?eUC|_DYUhnMtp3XVsuIRNuix$_kUj{NeKQ;o*TS9@kNx zt;iy|BkTC`f6-zQU82zC@WZ>o;Q0WvD39D{)u&OOuafJ#JRYRcZG1Jnj;6oQSJ_=U z8Ynu$cj90tE-Y&Cs zf+G3ja!;gY9QW@tnM!JnLh1a&`;X#%Ii>1@r?Gq!tyPlWMyq*}?(4y|S(FRGh+&N3 zVn}N&)k4E&O8E=T)~luexMCS!Szz6(#w;%Ihp!#8Fym%~yAEb3N;6v_Ocx zWL66+J|}se9hm>;Xt6%Vfb!$7ciU_4-1#b*y?oJ;q#^!1i#C`YSx4>J?XSiasp%zYL3M#E#u-G@Jh|Vzd$uOo^?&1OUK#tZJW6NL zYBsnS{G5FmKE)syfh4o5;Xmm1V(prTgCP&@t=2O83MosNpfFNI%iTrTr;s`o*Vnrm zR%k<%&KL1U3)oW27&uWNM}|mfrZ8T_x07kMO83KrQ`%LiDHvtnwhfyI!kIAk>D5Np zO`Obc@_J=JG_}uP4cBjdlRZp4@#A6V=)aLKpHSNv#?T(dMvedo4+>)AR4_RPMl?fx z7_rE(AZ}&VF%Wh^m!wZGp@KsAxhhJz>LP^ymZY%lca9kz_tCB`TVh-9aMD?kz! zQVTxD_ku}PK#hWFrg@sB=_F2Pg+-0*^onvV+(accw&BFmyW8nZL)Qb-0Ll z#n*e0*5)UJ8^nn7@Cb=KD`;)-^wX=M*)!GiU8ufGYrne*QFbPD5+depK`aSJmJ~#q zknsd+;e{41#|UE7s0fIlT-@5QW7wDzy3LR}FdJ_L6z2O0D8y-SY!PSSag4F5sc_6F zG4>2NZeduD<8ww8vMrD~F)k5e?veyVGACMDQQ#Lti?O3)W{gt{tm)N1I->B~xG$#& z)eNe;Oz^IR6Pu7g1P%#mAgJ0xP!Z{}f5wOnh(OfBg()G(twabKO{po=O34F5&}*Yl z%z!YgLZI#uxQ)PnW{bypmU=*_TW434C<^u7t)s9zR#Q zAr6SWQW9#*C`tQeuyk_!MGHfiU;Re>u5 z%oU-ivUXHlbZUd*s?JEi=muE&00z+@BP@=J=CJQ6XtV7-rlqn>44M|?j`W#EN|!uS zD+PK?D`lA*G}ZbFf9bWbRIqD29SzfH6Ut+$jku^MDqo)IP>dQlMtp2qZVgv@`MruO(^;#3XqQ(Gsv*H}s0mkNqs3uAo`+WtBz}nNJ+$=gk&`boq zyW!5GYZtyr1eW5~l*rP8g+x}ZkzUcS$P$M@h+&E;fMsMS_YObBU-DwRoGyUUyI27gO53E1ssp&%;Neee^^( zUEoY%={YGhCwXDmQ&JZxNw(k8FN$4~G_4~Yxusud z5yT3&r%$!hsO-1TN5B02Naxp3HG+RD4SYT;BItdMX`-zWwEi%t+0h! z8GIYZZ=`>>S_oDi`k>IY&YjRZF?BxDoWMs)%G5|BBZY3;DfNIVAV?7uZilf0rG(%5 zTEcmpqYsI_bNrT_W6gQP)*U*)iFCaNj0A1aacWqp2F9R>K-V)8ga$o3+upYRY}V-sSfUG{Z@JeB>{#3fb+Aa>6z3wtgG0! zY13w{JI34=rE%>NfioCX!?hS)P{NH-64Mw2rm!x(kkIro7sun!Yo%Y#8e2@08zDRQ zsEHjM!ueXQnK%Iy8B=nEYp*rcA}k!i<+kpqfD(!oXw*!MfM~EbXj5#xnSNQp0jH&a za(xiG+?iyBfu;uxzSV|n*1GS*^b0B^v-#Rfaz2CVV9^PwyX?GlcgRYQpj;}{uE<0RBJl0*(MnMYhN@8UNrGzu`il* zuv3ni6CB2*(mgc=!ahO<%0ubWy3+)l=|U&(Kw0K0+SE#{trA6&)4K^ F0060viAVqd literal 2203 zcmV;M2xRvkiwFP!000021MOT}Z`(!|e$THEl$S0bkLG@m_fZ{IT{72SrGOlssXkb>9{eKg;k;m32EGy37j&x^SC7-p*|O>X-H;eIbn zrs*t7=C}PnKK|oI_kX;5_roj-zK8$wELim56UoZHyY1iS`SSbW@agFZ#m}oCPcsxp z4`>w*{};q@Fa)7t|L$F{w>`it$OC(=x*Ftp7EK=Vu$Kgj@U}k*rhm<|^dXt`OQ}k3 zn#O6?dko^+{`*hGt3RxU8Saep!r04T9!|0__^WAv4807q{b3i&bQOU}{=7U8 zsTs%q+>)uJRv?tj@7{ml@5?Dw7dB(LCRz)UFM@0yC5Je$HgUNS6lqE+EQT=JV8s<# zugUA-CYObaFAJAl7A{(imuZ$~L6jdtPSP|EgQP^wvxl%b&T1OOK(Uw9YN5raD9_U) z^ZyjYt5XyxFMoO3Ui;+EvuO76gS#V9Gs;sm%kRgZJuO!``m?9eAEQ+?i9^@yqa;7u z@XzNNe*f+i)_e2umTV|Tt91`E9g0xA-aX78qFJ~)LbF|&nvw1+vEi{*-U|OAfhP91pOxn{}ivb~sc_p#75LAo^MT!C*L@dHDiCbxP3WaUZ zCGh6OrB@1XLt)Hh7b*O&C{U14pcf z2TJ5=Vb*$^zuxxsfvS$rlIpX#_Ot5{Wp6@fF~qDbi3MU{B{>q>XFLHYtUzI61SAGT zi3s;-oLGkh z+;d1!LqXY=f)WXv{ZopJM+O24`Y2qNEYMotSBr%Z#aJH2Dw1fa8Aguu)LYX#2a>W(o@o-(LhCE!t!iJFvNOJ?Df;#kD3ffG2k7=+d6N9D&xf6Y+7Q!aa*a!|D(+E-K22D|4 z;V+#U)(RH+J?~lph_@&JvA2o#Nb4;ng^VJiEYEQ5k-Y$f30JlbuaxE^usKu-Vv!~0 zzRQ?(YC4@Q#pQMZ1gKr(Fl)hK@@DZOA?0@HrWd}|mg z#E2uT!QWE&jcG&J+^)!x=A}KEx;tBRd+x~XHHQADrZ4n`W~#c*yfn#ONcMW~Q?Q8Q zXP8istoprG{#?1!@}s|m@ne`r(_owFub;s|Roqb-$4KMd7jFl;%fZum*aU00$E>E) zj0E;yJD?zr=E)*--_Q^OuWB(*L~(YIz3!QKET**oRBWcgE@PB<`w$AR$>7z^tx+J# z1}DdflJ=buU9d?X{{HjTD*3ibP9k27QWuSqXuq>x)Vu_0T24A~XTLz<$Z)&0kCjD~ zrVAG7=U+d3{PSv)eA^@^53e?hi7WL;?p7>}(7X z(|3Qn+9%)ksfLqR3-vWysJcxZb%uRz#>)m5>A5pq8(wVbK>lVoxtZanfEC`iblgh1 zcdj|7>Xdy*{b?`jTW~ypqOMMO2C-evoF9FW=uz_Dtt`wI7*fe`L(!mf$-7I&1?AB!Qu*S zfAU`=R-GR5YpDeITTQIL71-8)ZHu8QswaE<^y7KW0MR)ntt=e={$65>6SCv6w_pyi_U%f z#2ydH<+`saKLZshm0|#EuM}3?FCB@^aP8><$z{n#McIHLMU3&CQBTG1Q(;?NGil=0IN(VcHKC||Gd^syw^?KbiCG0 d-n4E~zAwJ`_U_%zH{;&D`#-(-r)xc5003VUJwyNi diff --git a/papers/software_fmea/software_fmea.tex b/papers/software_fmea/software_fmea.tex index ea0d156..f83b39b 100644 --- a/papers/software_fmea/software_fmea.tex +++ b/papers/software_fmea/software_fmea.tex @@ -175,10 +175,10 @@ it can be applied to electrical and/or mechanical systems. % The hierarchical structure of software is then examined, and definitions from contract programming are used -to define failure modes and failure symptoms in +to define failure modes and failure symptoms for software functions. % -With these definitions we can apply a modular form of FMEA +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}. } @@ -222,11 +222,12 @@ base component {\fms}, and translating them into system level events/failures~\c In a complicated system, mapping a component failure mode to a system level failure will mean a long reasoning distance; that is to say the actions of the failed component will have to be traced through several sub-systems and the effects of other components on the way. +% With software at the higher levels of these sub-systems -we have another layer of complication. +we have yet another layer of complication. In order to integrate software, in a meaningful way we need to re-think the -FMEA concept of mapping a base component failure to a system level event. +FMEA concept of simply mapping a base component failure to a system level event. One strategy would be to modularise FMEA. To break down the failure effect @@ -234,16 +235,16 @@ reasoning into small modules. % If we pre-analyse modules, and then they can be combined with others, into -larger sub-systems, and eventually form a hierarchy of failure mode behaviour for the entire system. +larger sub-systems, we can eventually form a hierarchy of failure mode behaviour for the entire system. % -With higher level modules, we can approach the level that the software re-sides in. +With higher level modules, we can reach the level that the software resides in. % For instance, to read a voltage into software via an ADC we rely on an electronic sub-system that conditions the input signal and then routes it through a multiplexer to the ADC. % -We could easily consider this electronics a module, and with a -failure mode model for it, it makes modelling the software to hardware interface -far simpler. +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. % The failure mode model, would give us the ways in which the signal conditioning and multiplexer could fail. We can use this to work out how our software @@ -251,7 +252,7 @@ could fail, and with this create a modular FMEA model of the software. -\section{Modularising FMEA} +\section{Modularising FMEA: The FMMD process in more detail.} In outline, in order to modularise FMEA, we must create small modules from the bottom-up. We can do this by taking collections of base~components that @@ -331,8 +332,9 @@ 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; and how its symptoms of failure are determined. +That is to say their component failure modes are examined, and thus +the ways in which the {\fgs} can fail. The ways in which a +{\fg} can fail, can be viewed as symptoms of failure for the {\fg}. % The `$\bowtie$' function is now applied to create {\dcs}. These are shown in figure~\ref{fig:fmmdh} above the {\fgs}. @@ -373,8 +375,9 @@ are the failure modes of the software components (other functions it calls) and the hardware its reads values from. Its outputs are the data it changes, or the hardware actions it performs. -When we have analysed a software function, initially using its input failure modes -we can determine its symptoms of failure (how calling functions will see its failure mode behaviour). +When we have analysed a software function---using failure conditions +of its inputs as failure modes---we can +determine its symptoms of failure (i.e. how calling functions will see its failure mode behaviour). We can thus apply the $\bowtie$ process to software functions, by viewing them in terms of their failure mode behaviour. To simplify things as well, software already fits into a hierarchy. @@ -393,7 +396,7 @@ and the subsequent hierarchy. With software already written, that hierarchy is f \subsection{Software, a natural hierarchy} Software written for safety critical systems is usually constrained to -be modular~\cite{en61508}[3] and non recursive~\cite{misra}[15.2].%{iec61511}. +be modular~\cite{en61508}[3] and non recursive~\cite{misra}[15.2]. %{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. @@ -482,7 +485,7 @@ value from the external equipment. \subsection{Simple Software Example} -Consider a function that reads a {\ft} input, and returns a value between 0 and 999 (i.e. per mil $\permil$) +Consider a software 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 additional error indication flag . % Let us assume the {\ft} detection is via a \ohms{220} resistor, and that we read a voltage @@ -503,7 +506,7 @@ a per~mil representation of the {\ft} input current. % For the purpose of example the `C' programming language is used. We initially assume a function \textbf{read\_ADC} which returns a floating point %double precision -value which holds the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}). +value which represents the voltage read (see code sample in figure~\ref{fig:code_read_4_20_input}). %%{\vbox{ @@ -559,7 +562,7 @@ deals directly with the hardware in the micro-controller that we are running the Its job is to select the correct channel (ADC multiplexer) and then to initiate a conversion by setting an ADC 'go' bit (see code sample in figure~\ref{fig:code_read_ADC}). % -It takes the raw ADC reading and converts it into a i +It takes the raw ADC reading and converts it into a floating point\footnote{the type, `double' or `double precision', is a standard C language floating point type~\cite{kandr}.} voltage value. @@ -631,7 +634,7 @@ We now have a very simple software structure, a call tree, shown in figure~\ref{ \label{fig:ct1} \end{figure} -This software is above the hardware in the conceptual call tree---by that, in software terms---the +This software is above the hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the software is reading values from the `lower~level' electronics. % FMEA is always a bottom-up process and so we must begin with this hardware. @@ -651,12 +654,13 @@ We now apply FMMD starting with the hardware. This functional group contains the load resistor and the physical Analogue to Digital Converter (ADC). -Our functional group, G is thus the set of base components $G = \{R, ADC\}$. +Our functional group, $G_1$ is thus the set of base components: $G_1 = \{R, ADC\}$. +We now determine the {\fms} of all the components in $G_1$. For the resistor we can use a failure mode set from the literature~\cite{en298}. Where the function $fm$ returns a set of failure modes for a given component we can state: $$ fm(R) = \{OPEN,SHORT\}. $$ - +\vbox{ For the ADC we can determine the following failure modes: \begin{itemize} @@ -665,16 +669,16 @@ For the ADC we can determine the following failure modes: \item LOW --- The ADC output is always LOW, or zero ADC counts, \item HIGH --- The ADC output is always HIGH, or max ADC counts. \end{itemize} - +} We can use the function $fm$ to define the {\fms} of an ADC thus: $$ fm(ADC) = \{ STUCKAT, MUXFAIL,LOW, HIGH \}. $$ -With these failure modes, we can analyse our first functional group, see table~ref{tbl:cmatv}. +With these failure modes, we can analyse our first functional group, see table~\ref{tbl:cmatv}. { \tiny \begin{table}[h+] -\caption{CMATV: Failure Mode Effects Analysis} % title of Table +\caption{$G_1$: Failure Mode Effects Analysis} % title of Table \label{tbl:cmatv} \begin{tabular}{|| l | c | l ||} \hline @@ -711,11 +715,14 @@ With these failure modes, we can analyse our first functional group, see table~r } -We now have the symptoms for the hardware functional group, $\{ HIGH , LOW, V\_ERR \} $. +We now collect the symptoms for the hardware functional group, $\{ HIGH , LOW, V\_ERR \} $. We now create a {\dc} to represent this called $CMATV$. -As its failure modes, are the symptoms of failure from the functional group we can now state: -$$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} $$ +We can express this using the `$\bowtie$' function thus: +$$ CMATV = \; \bowtie (G_1) .$$ + +As its failure modes, are the symptoms of failure from the functional group we can now state: +$$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$$ \paragraph{Functional Group - Software - Read\_ADC - RADC} @@ -723,25 +730,31 @@ $$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} $$ The software function $Read\_ADC$ uses the ADC hardware analysed as the {\dc} CMATV above. -We know from the contractual programming requirements, that -the function needs to be sent the correct channel number. + +The code fragment in figure~\ref{fig:code_read_ADC} states pre-conditions, as +{\em/* require: a) input channel from ADC to be + in valid ADC range + b) voltage ref is 0.1\% of 5V */}. +% +From the above contractual programming requirements, we see that +the function must be sent the correct channel number. % A violation of this can be considered a {\fm} of the function, which we can call $ CHAN\_NO $. % -The reference voltage for the ADC has a 0.1\% requirement. +The reference voltage for the ADC has a 0.1\% accuracy requirement. % If the reference value is outside of this, it is also a {\fm} of this function, which we can call $V\_REF$. Taken as a component for use in FMEA/FMMD our function has -two failure modes. We can therefore treat it as a generic component, $RA$, +two failure modes. We can therefore treat it as a generic component, $Read\_ADC$, by stating: -$$ fm(RA) = \{ CHAN\_NO, VREF \} $$ +$$ 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}, where $G=\{ CMSTV, Read\_ADC \}$. +with 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}. @@ -750,17 +763,17 @@ We now analyse this hardware/software combined {\fg}. { \tiny \begin{table}[h+] -\caption{RADC: Failure Mode Effects Analysis} % title of Table +\caption{$G_2$: Failure Mode Effects Analysis} % title of Table \label{tbl:radc} \begin{tabular}{|| l | c | l ||} \hline \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline \hline - 1: $RA_{CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\ + 1: ${CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\ & read & \\ \hline - 2: $RA_{VREF}$ & voltage & $VV\_ERR$ \\ + 2: ${VREF}$ & voltage & $VV\_ERR$ \\ & incorrect & \\ \hline \hline @@ -786,13 +799,13 @@ We now analyse this hardware/software combined {\fg}. -We now have the symptoms of failure for the {\fg} analysed (see table~\ref{tbl:radc}) +We now collect the symptoms of failure for the {\fg} analysed (see table~\ref{tbl:radc}) as $\{ VV\_ERR, HIGH, LOW \}$. We can add as well the violation of the postcondition for the function. This postcondition, {\em /* ensure: value is voltage input to within 0.1\% */ }, corresponds to $VV\_ERR$, and is already in the {\fm} set for this {\fg}. -We can now create a {\dc} called $RADC$ which has the following +We can now create a {\dc} called $RADC$ thus: $$RADC = \; \bowtie(G_2)$$ which has the following {\fms}: $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$ @@ -804,22 +817,23 @@ $$ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$$ \paragraph{Functional Group - Software - voltage to per mil - VTPM } This function sits on top of the $RADC$ {\dc} determined above. -We look at the pre-conditions for the function $read\_4\_20\_input$ $(RI)$, % which we can call $RI$ +We look at the pre-conditions for the function $read\_4\_20\_input$ , % which we can call $RI$ to determine its {\fms}. Its pre-condition is, {\em /* require: input from ADC to be between 0.88 and 4.4 volts */}. We can map this violation of the pre-condition, to the {\fm} VRNGE; %As this function has one pre-condition we can state, -$$ fm(RI) = \{ VRNGE \} .$$ +$$ fm(read\_4\_20\_input) = \{ VRNGE \} .$$ -We can now form a functional group with the {\dc} $RADC$ and the software component $RI$, i.e. $G=\{RI, RADC\}$. +We can now form a functional group with the {\dc} $RADC$ and the +software component $read\_4\_20\_input$, i.e. $G_3 = \{read\_4\_20\_input, RADC\} $. { \tiny \begin{table}[h+] -\caption{Read\_4\_20: Failure Mode Effects Analysis} % title of Table +\caption{$G_3$: Read\_4\_20: Failure Mode Effects Analysis} % title of Table \label{tbl:r420i} \begin{tabular}{|| l | c | l ||} \hline @@ -852,7 +866,7 @@ We can now form a functional group with the {\dc} $RADC$ and the software compon } The failure symptoms for the {\fg} are $\{OUT\_OF\_RANGE, VAL\_ERR\}$. -The postcondition for the function $read\_4\_20\_input$ ($R420I$), {\em /* ensure: value is proportional (0-999) to the +The postcondition for the function $read\_4\_20\_input$, {\em /* ensure: value is proportional (0-999) to the 4 to 20mA input */} corresponds to the $VAL\_ERR$ and is already in the set of failure modes. % \paragraph{Final Functional Group} For single failures these are the two ways in which this function @@ -861,7 +875,10 @@ The $VAL\_ERR$ will simply mean that the value read is simply wrong. We can finally make a {\dc} to represent a failure mode model for our function $read\_4\_20\_input$ thus: -$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\}$$ +$$ R420I = \; \bowtie(G_3) .$$ + +This new {\dc} has the following {\fms}: +$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$$ % % Using the derived components, CMATV and VTPM we create