From 89599b184c83042165b87873e7a5b860c46ce5c8 Mon Sep 17 00:00:00 2001 From: robin Date: Sat, 21 Apr 2012 13:45:29 +0100 Subject: [PATCH] Added software FMMD to CH5 and altered images to use D instead of bowtie. Just need to to the write-up of the sigma delta now. --- papers/fmmd_software_hardware/hd.dia | Bin 2335 -> 2384 bytes papers/software_fmea/hd.dia | Bin 2335 -> 2384 bytes submission_thesis/CH5_Examples/Makefile | 2 +- submission_thesis/CH5_Examples/copy.tex | 621 +++++++++++++++++- .../CH8_finish_appendixes/copy.tex | 11 + submission_thesis/Makefile | 6 +- submission_thesis/mybib.bib | 9 + submission_thesis/style.tex | 1 + submission_thesis/thesis.tex | 8 +- 9 files changed, 654 insertions(+), 4 deletions(-) create mode 100644 submission_thesis/CH8_finish_appendixes/copy.tex diff --git a/papers/fmmd_software_hardware/hd.dia b/papers/fmmd_software_hardware/hd.dia index 5f7b599677112e978796168e0336d8fb10a30874..9d8a7300d47fd025e62733cf2cc0a704aa7e446a 100644 GIT binary patch literal 2384 zcmV-W39t4aiwFP!000021MOW~Z{xTXexF}qcwSn-VR(4wdNYgJU36Pu7cI8az8Z?H zanyAr!&Z{XOMiPwNuKyZ`68N5)R6}hzz)q%hx+uL3y+lVfB14g>pjMcWs;>geL%S1 zi_>v7Nz&;}|6iZ}a;5q|e0cZ$B#FK=|EG)SzGuFXF73OU{#~BWzq`JEdU`^$=Vg>< z3p7g}&@#UMZ#0`l*JjXl|HHdpZ+(JElt=cn>eDFC7s>5I9{1AdKECPSM&m!Gi|iqt z^vhAzxN$bi7QM%4cGG|Vxp?)jt7)z`=Gim%JetP0i#YnDerjx9S~r<`9xt}1y`N{x z#0<%w=Q~4c=CME5##E!0W>7l)@ctuvUmjBR!OL8(1FZ$g@1w;uNq2F~+RVy@AV?8H z%wlk@G?q-lYE4duyS*&j?6Po+%fcng(L7t^izvx=A#by67Ds7`nlB#W<~Yl7G&2<2 zXO@Q*pOZY#4jljIXtq4Yfb!$7SKFyq?sSn%_FuRgBWh-ON+$W;=u4pGDrbKVH2Y(+ zOm1hf>*$j-Kil-r=b3){>=f$#@^w!(l(W^khlz@L%uja@(}!ddFAvacb4<-lch#`# zL#w_$?%0JXKiYEE1;i|Rju+MRKfbu>UUh;i#py-kJb7HbTU(Rt_CN7BuZ;a?9;K6L zG3j0Pe$2k~Ut$mwfh3cg{@?NDVr`peCNny?vs&})E2T6d48uSm$+s6_S3>F_Zf~~{ z7RH7sozCJF3g{AL2owq61BEy=1B_?!{b-ym(%mrOoOTs3g`(`*wo(&@C}B#!ynL|k z;$(W4*Mk9)Sg*etuHW)5dm1_7$HUIieIZ}Ju(mOc!Jo#84*(DiN@8Up2p4YZ&GWWSwwTj zmphTx>NmYR!x8J@4JGodkhR{+Z*Tf)$5h96q53Ya{q8D6**c)J2r=~~F-O#>Btu+< zj3*2VEl?;Q8WI~sfq(_oVsFEaQDchmrb5cVYP=CpsQ;gUf}MxQ+VCtqk4>zqDjpMz zl)eCuJq+u3e95SS`x2QVWfLJ{Pf0)~QzV6E1%FLwF|=|_l(Miunx6fmBMP^TyW<4H zl0bEpG1``JVigjwz#%~m1%)pK1>!dQCj{w$3^XW|sgiu^{3a#tcPftT41Qvu0qfG{v=%UV(@HUx}_0_M1IS$#8l z-!=+U4+=wI3V({f=#9Z-nuKR=*omQ2(8*nL7{qhQry9*N@I z**xuJ?36nfs2xJHfu`-g*gMTVfk;0ndKtD!^;q_FRr)^{$cNFRUxsnev; zn&hNmCrNFTB=D~{7nvhRO_Q=C>&*oULz>xwGnN)n=(n#&KmGRc)4w}K3av;^7Iuo% zMn&>(N5Ef0=AgY{YdB!iHX}|%m2X?1OXg~wj7+ffr$2Y%6k42W2-(TgTb8Gqswj9j zngBtRl{+pXaI2KktSE|VPHgKR)l3(#Ja|#mZKS(TiZN1lBw}dWw$dxrHG!SMM{-QW zKpI5~>?1225CsLXA%(5ix1f~pdsj=ijB|7`v2%`Z**VrU!+ZDq07cyH+z}LXx7)&y z5(b7K5Hqf4zz`04V~4+OU0eJm8`wacA<_e?xxJSML(uY=LBc|lfk{27#?({;OJ&$7dW=Ds^Z;j1`5%tk2S1DapP$fSWnBbt@-0Q=cgL9BqExnBB5(#{V5nq+D~za8f}1qP5R++} zUT|o759aYabXw^iry58*O5GZK7;)I-~3^9qpGVG|E+GwCanfUqG* zM7cfLga*x|{f+A$k`N@7u1P@%oIzHL$6^?6X&zQrOB_I)@nLa8gwZ(zt6EU7W(5DO zOFV)n9&RpniAM{&O$hOC$py^qZE+Cx9ziJYlH%HS<3MR69g0Rp?C^deldVA=#`Maa%& zbuNhqvfKY1^pdCe$t_R$bFH7;tFFiUN^fu3^OLK=Tpt=NOaxI3mWXJdb$ru)m*VqqPKat@*=0B< zR_8`ZkcM`^pgOV2C*14&?l<9g_wcpzyY2A1<=f(~ntgb;@n_FIy!#)$N(?O;bpQY+ CYnMv^ 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 diff --git a/papers/software_fmea/hd.dia b/papers/software_fmea/hd.dia index 5f7b599677112e978796168e0336d8fb10a30874..9d8a7300d47fd025e62733cf2cc0a704aa7e446a 100644 GIT binary patch literal 2384 zcmV-W39t4aiwFP!000021MOW~Z{xTXexF}qcwSn-VR(4wdNYgJU36Pu7cI8az8Z?H zanyAr!&Z{XOMiPwNuKyZ`68N5)R6}hzz)q%hx+uL3y+lVfB14g>pjMcWs;>geL%S1 zi_>v7Nz&;}|6iZ}a;5q|e0cZ$B#FK=|EG)SzGuFXF73OU{#~BWzq`JEdU`^$=Vg>< z3p7g}&@#UMZ#0`l*JjXl|HHdpZ+(JElt=cn>eDFC7s>5I9{1AdKECPSM&m!Gi|iqt z^vhAzxN$bi7QM%4cGG|Vxp?)jt7)z`=Gim%JetP0i#YnDerjx9S~r<`9xt}1y`N{x z#0<%w=Q~4c=CME5##E!0W>7l)@ctuvUmjBR!OL8(1FZ$g@1w;uNq2F~+RVy@AV?8H z%wlk@G?q-lYE4duyS*&j?6Po+%fcng(L7t^izvx=A#by67Ds7`nlB#W<~Yl7G&2<2 zXO@Q*pOZY#4jljIXtq4Yfb!$7SKFyq?sSn%_FuRgBWh-ON+$W;=u4pGDrbKVH2Y(+ zOm1hf>*$j-Kil-r=b3){>=f$#@^w!(l(W^khlz@L%uja@(}!ddFAvacb4<-lch#`# zL#w_$?%0JXKiYEE1;i|Rju+MRKfbu>UUh;i#py-kJb7HbTU(Rt_CN7BuZ;a?9;K6L zG3j0Pe$2k~Ut$mwfh3cg{@?NDVr`peCNny?vs&})E2T6d48uSm$+s6_S3>F_Zf~~{ z7RH7sozCJF3g{AL2owq61BEy=1B_?!{b-ym(%mrOoOTs3g`(`*wo(&@C}B#!ynL|k z;$(W4*Mk9)Sg*etuHW)5dm1_7$HUIieIZ}Ju(mOc!Jo#84*(DiN@8Up2p4YZ&GWWSwwTj zmphTx>NmYR!x8J@4JGodkhR{+Z*Tf)$5h96q53Ya{q8D6**c)J2r=~~F-O#>Btu+< zj3*2VEl?;Q8WI~sfq(_oVsFEaQDchmrb5cVYP=CpsQ;gUf}MxQ+VCtqk4>zqDjpMz zl)eCuJq+u3e95SS`x2QVWfLJ{Pf0)~QzV6E1%FLwF|=|_l(Miunx6fmBMP^TyW<4H zl0bEpG1``JVigjwz#%~m1%)pK1>!dQCj{w$3^XW|sgiu^{3a#tcPftT41Qvu0qfG{v=%UV(@HUx}_0_M1IS$#8l z-!=+U4+=wI3V({f=#9Z-nuKR=*omQ2(8*nL7{qhQry9*N@I z**xuJ?36nfs2xJHfu`-g*gMTVfk;0ndKtD!^;q_FRr)^{$cNFRUxsnev; zn&hNmCrNFTB=D~{7nvhRO_Q=C>&*oULz>xwGnN)n=(n#&KmGRc)4w}K3av;^7Iuo% zMn&>(N5Ef0=AgY{YdB!iHX}|%m2X?1OXg~wj7+ffr$2Y%6k42W2-(TgTb8Gqswj9j zngBtRl{+pXaI2KktSE|VPHgKR)l3(#Ja|#mZKS(TiZN1lBw}dWw$dxrHG!SMM{-QW zKpI5~>?1225CsLXA%(5ix1f~pdsj=ijB|7`v2%`Z**VrU!+ZDq07cyH+z}LXx7)&y z5(b7K5Hqf4zz`04V~4+OU0eJm8`wacA<_e?xxJSML(uY=LBc|lfk{27#?({;OJ&$7dW=Ds^Z;j1`5%tk2S1DapP$fSWnBbt@-0Q=cgL9BqExnBB5(#{V5nq+D~za8f}1qP5R++} zUT|o759aYabXw^iry58*O5GZK7;)I-~3^9qpGVG|E+GwCanfUqG* zM7cfLga*x|{f+A$k`N@7u1P@%oIzHL$6^?6X&zQrOB_I)@nLa8gwZ(zt6EU7W(5DO zOFV)n9&RpniAM{&O$hOC$py^qZE+Cx9ziJYlH%HS<3MR69g0Rp?C^deldVA=#`Maa%& zbuNhqvfKY1^pdCe$t_R$bFH7;tFFiUN^fu3^OLK=Tpt=NOaxI3mWXJdb$ru)m*VqqPKat@*=0B< zR_8`ZkcM`^pgOV2C*14&?l<9g_wcpzyY2A1<=f(~ntgb;@n_FIy!#)$N(?O;bpQY+ CYnMv^ 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 diff --git a/submission_thesis/CH5_Examples/Makefile b/submission_thesis/CH5_Examples/Makefile index 012686d..2749f47 100644 --- a/submission_thesis/CH5_Examples/Makefile +++ b/submission_thesis/CH5_Examples/Makefile @@ -4,7 +4,7 @@ PNG_DIA = blockdiagramcircuit2.png bubba_oscillator_block_diagram.png circuit1 dubsim1.png invamp.png mvampcircuit.png pd.png plddouble.png plddoublesymptom.png \ poss1finalbubba.png poss2finalbubba.png pt100.png pt100_doublef.png pt100_singlef.png \ pt100_tc.png pt100_tc_sp.png shared_component.png stat_single.png three_tree.png \ - tree_abstraction_levels.png vrange.png sigma_delta_block.png + tree_abstraction_levels.png vrange.png sigma_delta_block.png ftcontext.png ct1.png hd.png diff --git a/submission_thesis/CH5_Examples/copy.tex b/submission_thesis/CH5_Examples/copy.tex index 804cb36..fc58130 100644 --- a/submission_thesis/CH5_Examples/copy.tex +++ b/submission_thesis/CH5_Examples/copy.tex @@ -2677,7 +2677,626 @@ because here we have found a fault that we cannot detect at this level. This means that should we wish to cope with this fault, we need to devise a way of detecting this condition in higher levels of the system. -\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period.}} +\glossary{name={FIT}, description={Failure in Time (FIT). The number of times a particular failure is expected to occur in a $10^{9}$ hour time period. Associated with continuous demand systems under EN61508~\cite{en61508}}} + + + + +\section{Applying FMMD to Software} + +FMMD can be applied to software, and thus we can build complete failure models +of typical modern safety critical systems. +With modular FMEA i.e. FMMD %(FMMD) +we have the concepts of failure~modes +of components, {\fgs} and symptoms of failure for a functional group. + +A programmatic function has similarities with a {\fg} as defined by the FMMD process. +% +An FMMD {\fg} is placed into a hierarchy. +A Software function is placed into a hierarchy, that of its call-tree. +A software function typically calls other functions and uses data sources via hardware interaction, which could be viewed as its `components'. +It has outputs, i.e. it can perform actions +on data or hardware +which will be used by functions that may call it. + +We can map a software function to a {\fg} in FMMD. Its failure modes +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---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 $\derivec$ 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. +For Electronics and Mechanical systems, although we may be guided by the original designers +concepts of modularity and sub-systems in design, applying FMMD means deciding on the members for {\fgs} +and the subsequent hierarchy. With software already written, that hierarchy is fixed. + +% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% +%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% failure modes of a function in order to +%map FMMD to software. + + + +% map the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% +%However, we need to map a the FMMD concepts of {\fms}, {\fgs} and {\dcs} +%to software functions. +% failure modes of a function in order to +%map FMMD to software. + +\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}. +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. + +What is potentially difficult with a software function, is deciding what +are failure modes, and later what a failure symptoms. +With electronic components, we can use literature to point us to suitable sets of +{\fms}~\cite{fmd91}~\cite{mil1991}~\cite{en298}.%~\cite{en61508}~\cite{en298}. +With software, only some library functions are well known and rigorously documented +enough to have the equivalent of known failure modes. +Most software is `bespoke'. We need a different strategy to +describe the failure mode behaviour of software functions. +We can use definitions from contract programming to assist here. + +\subsection{Contract programming description} + +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). + + +\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 +to operate successfully. + +For a software function, a violation of a pre-condition is +in effect a failure mode of `one of its components'. + + +\paragraph{Mapping contract `post-condition' violations to symptoms} + +A post condition is a definition of correct behaviour by a function. +A violated post condition is a symptom of failure of a function. +Post conditions could be either actions performed (i.e. the state of hardware changed) or an output value of a function. + +\paragraph{Mapping contract `invariant' violations to symptoms and failure modes} + +Invariants in contract programming may apply to inputs to the function (where they can be considered {\fms} in FMMD terminology), +and to outputs (where they can be considered {failure symptoms} in FMMD terminology). + + +\subsection{Combined Hardware/Software FMMD} + +For the purpose of example, we chose a simple common safety critical industrial circuit +that is nearly always used in conjunction with a programmatic element. +A common method for delivering a quantitative value in analogue electronics is +to supply a current signal to represent the value to be sent~\cite{aoe}[p.934]. +Usually, $4mA$ represents a zero or starting value and $20mA$ represents the full scale, +and this is referred to as {\ft} signalling. +% +{\ft} has a an electrical advantage as well, because the current in a loop is constant~\cite{aoe}[p.20] +resistance in the wires between the source and the receiving end is not an issue +that can alter the accuracy of the signal. +% +This circuit has many advantages for safety. If the signal becomes disconnected +it reads an out of range $0mA$ at the receiving end. This is outside the {\ft} range, +and is therefore easy to detect as an error rather than an incorrect value. +% +Should the driving electronics go wrong at the source end, it will usually +supply far too little or far too much current, making an error condition easy to detect. +% +At the receiving end, we only require one simple component to convert the +current signal into a voltage that we can read with an ADC: the humble resistor! + + +%BLOCK DIAGRAM HERE WITH FT CIRCUIT LOOP + +\begin{figure}[h] + \centering + \includegraphics[width=230pt]{./CH5_Examples/ftcontext.png} + % ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385 + \caption{Context Diagram for {\ft} loop} + \label{fig:ftcontext} +\end{figure} + + +The diagram in figure~\ref{fig:ftcontext}, shows some equipment which is sending a {\ft} +signal to a micro-controller system. +The signal is locally driven over a load resistor, and then read into the micro-controller via +an ADC and its multiplexer. +With the voltage detected at the ADC the multiplexer can read the intended quantitative +value from the external equipment. + +\subsection{Simple Software Example} + + +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 +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 \ge 0.88) \wedge (V \le 4.4) \; .$$ + +This voltage range forms our input requirement. +% +We can now examine a software function that performs a conversion from the voltage read to +a per~mil representation of the {\ft} input current. +% +For the purpose of example the `C' programming language~\cite{kandr} is used. +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}). + + +%%{\vbox{ +\begin{figure}[h+] + +\footnotesize +\begin{verbatim} +/***********************************************/ +/* read_4_20_input() */ +/***********************************************/ +/* 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 + +\caption{Software Function: \textbf{read\_4\_20\_input}} +\label{fig:code_read_4_20_input} +%\label{fig:420i} +\end{figure} +\clearpage +We now look at the function called by \textbf{read\_4\_20\_input}, \textbf{read\_ADC}, which returns a +voltage for a given ADC channel. +% +This function +deals directly with the hardware in the micro-controller that we are running the software on. +% +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 +floating point\footnote{the type, `double' or `double precision', is a standard C language floating point type~\cite{DBLP:books/ph/KernighanR88}.} +voltage value. + + + + + +%{\vbox{ +\begin{figure}[h+] + +\footnotesize +\begin{verbatim} +/***********************************************/ +/* read_ADC() */ +/***********************************************/ +/* Software function to read voltage from a */ +/* specified ADC MUX channel */ +/* Assume 10 ADC MUX channels 0..9 */ +/* ADC_CHAN_RANGE = 9 */ +/* Assume ADC is 12 bit and ADCRANGE = 4096 */ +/* returns voltage read as double precision */ +/***********************************************/ +double read_ADC( int channel ) { + int timeout = 0; + /* require: a) input channel from ADC to be + in valid ADC range + b) voltage ref is 0.1% of 5V */ + + /* return out of range result */ + /* if invalid channel selected */ + if ( channnel > ADC_CHAN_RANGE ) + return -2.0; + + /* set the multiplexer to the desired channel */ + ADCMUX = channel; + + ADCGO = 1; /* initiate ADC conversion hardware */ + + /* wait for ADC conversion with timeout */ + while ( ADCGO == 1 || timeout < 100 ) + timeout++; + + if ( timeout < 100 ) + dval = (double) ADCOUT * 5.0 / ADCRANGE; + else + dval = -1.0; /* indicate invalid reading */ + + /* return voltage as a floating point value */ + + /* ensure: value is voltage input to within 0.1% */ + + return dval; +} +\end{verbatim} +\caption{Software Function: \textbf{read\_ADC}} +\label{fig:code_read_ADC} +\end{figure} +%} +%} +\clearpage + +We now have a very simple software structure, a call tree, shown in figure~\ref{fig:ct1}. + +\begin{figure}[h] + \centering + \includegraphics[width=100pt]{./CH5_Examples/ct1.png} + % ct1.png: 151x224 pixel, 72dpi, 5.33x7.90 cm, bb=0 0 151 224 + \caption{Call tree for software example} + \label{fig:ct1} +\end{figure} + +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. +% +The hardware is simply a load resistor, connected across an ADC input +pin on the micro-controller and ground. +% +We can identify the resistor and the ADC module of the micro-controller as +the base components in this design. +% +We now apply FMMD starting with the hardware. + + +\subsection{FMMD Process} + +\paragraph{Functional Group - Convert mA to Voltage - CMATV} + +This functional group contains the load resistor +and the physical Analogue to Digital Converter (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} + \item STUCKAT --- The ADC outputs a constant value, + \item MUXFAIL --- The ADC cannot select its input channel correctly, + \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}. + +{ +\tiny +\begin{table}[h+] +\caption{$G_1$: Failure Mode Effects Analysis} % title of Table +\label{tbl:cmatv} + +\begin{tabular}{|| l | c | l ||} \hline + \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ + \textbf{Scenario} & \textbf{effect} & \textbf{ADC } \\ \hline + \hline + 1: $R_{OPEN}$ & resistor open, & $HIGH$ \\ + & voltage on pin high & \\ \hline + + 2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\ + & voltage on pin low & \\ \hline \hline + + + + 3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\ + & fixed value & \\ \hline + + + + 4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\ + & wrong channel & \\ \hline + + 5: $ADC_{LOW}$ & output low & $LOW$ \\ + 6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline + + +\hline + + +\hline + +\end{tabular} +\end{table} +} + + +We now collect the symptoms for the hardware functional group, $\{ HIGH , LOW, V\_ERR \} $. +We now create a {\dc} to represent this called $CMATV$. + +We can express this using the `$\derivec$' function thus: +$$ CMATV = \; \derivec (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} + +The software function $Read\_ADC$ uses the ADC hardware analysed +as the {\dc} CMATV above. + + +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\% 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, $Read\_ADC$, +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 \}$. + +We now analyse this hardware/software combined {\fg}. + + + +{ +\tiny +\begin{table}[h+] +\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: ${CHAN\_NO}$ & wrong voltage & $VV\_ERR$ \\ + & read & \\ \hline + + 2: ${VREF}$ & ADC volt-ref & $VV\_ERR$ \\ + & incorrect & \\ \hline \hline + + + + 3: $CMATV_{V\_ERR}$ & voltage value & $VV\_ERR$ \\ + & incorrect & \\ \hline + + + + 4: $CMATV_{HIGH}$ & ADC may read & $HIGH$ \\ + & wrong channel & \\ \hline + + 5: $CMATV_{LOW}$ & output low & $LOW$ \\ \hline + +\hline + + +\hline + +\end{tabular} +\end{table} +} + + + +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$ thus: $$RADC = \; \derivec(G_2)$$ which has the following +{\fms}: + +$$ 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$ , % 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(read\_4\_20\_input) = \{ VRNGE \} .$$ + +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{$G_3$: Read\_4\_20: Failure Mode Effects Analysis} % title of Table +\label{tbl:r420i} + +\begin{tabular}{|| l | c | l ||} \hline + \textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\ + \textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline + \hline + 1: $RI_{VRGE}$ & voltage & $OUT\_OF\_$ \\ + & outside range & $RANGE$ \\ \hline + + 2: $RADC_{VV_ERR}$ & voltage & $VAL\_ERR$ \\ + & incorrect & \\ \hline \hline + + + + 3: $RADC_{HIGH}$ & voltage value & $VAL\_ERR$ \\ + & incorrect & \\ \hline + + + + 4: $RADC_{LOW}$ & ADC may read & $OUT\_OF\_$ \\ + & wrong channel & $RANGE$ \\ \hline + +\hline + + +\hline + +\end{tabular} +\end{table} +} + +The failure symptoms for the {\fg} are $\{OUT\_OF\_RANGE, VAL\_ERR\}$. +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 +can fail. An $OUT\_OF\_RANGE$ will be flagged by the error flag variable. +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: + +$$ R420I = \; \derivec(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 +% a new functional group. This +% integrates FMEA's from software and eletronics +% into the same failure mode model. + + + +We can now represent the software/hardware FMMD analysis +as a hierarchical diagram, see figure~\ref{fig:hd}. + +\begin{figure}[h] + \centering + \includegraphics[width=200pt]{./CH5_Examples/hd.png} + % hd.png: 363x520 pixel, 72dpi, 12.81x18.34 cm, bb=0 0 363 520 + \caption{FMMD hierarchy with hardware and software elements} + \label{fig:hd} +\end{figure} + + + +We can represent the hierarchy in figure~\ref{fig:hd} algebraically, using the `$\derivec$' function +using the groups as intermediate stages: +\begin{eqnarray*} +G_1 = \{R,ADC\} \\ +CMATV = \;\derivec (G_1) \\ +G_2 = \{CMATV, read\_ADC \} \\ +RADC = \; \derivec (G_2) \\ +G_3 = \{ RADC, read\_4\_20\_input \} \\ +R420I = \; \derivec (G_3) \\ +\end{eqnarray*} +or, a nested definition, +$$ \derivec \Big( \derivec \big( \derivec(R,ADC), read\_4\_20\_input \big), read\_4\_20\_input \Big). $$ + + + + + +This nested structure means that we have multiple traceable +stages of failure mode reasoning in our analysis. Traditional FMEA would have only one stage +of reasoning for each component failure mode. + +%\clearpage +\subsection{Conclusion: Software/Hardware FMMD Model} + +The {\dc} representing the {\ft} reader +in software shows that by FMMD, we can integrate +software and electro-mechanical FMMD models. +With this analysis +we have a complete `reasoning~path' linking the failures modes from the +electronics to those in the software. +Each functional group to {\dc} transition represents a +reasoning stage. +% + +With traditional FMEA methods the reasoning~distance is large, because +it stretches from the component failure mode to the top---or---system level failure. +For this reason applying traditional FMEA to software stretches +the reasoning distance even further. + +We now have a {\dc} for a {\ft} input in software. +Typically, more than one such input could be present in a real-world system. +Not only have we integrated electronics and software in an FMEA, we can also +re-use the analysis for each {\ft} input in the system. + +The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed +by another software function to read other known signals +via the MUX (i.e. voltage references). This strategy would +detect ADC\_STUCK\_AT and MUX\_FAIL failure modes. +% +%Detailing this however, is beyond the scope %and page-count +%of this paper. + + + +%Its solved. Hoooo-ray !!!!!!!!!!!!!!!!!!!!!!!! + + diff --git a/submission_thesis/CH8_finish_appendixes/copy.tex b/submission_thesis/CH8_finish_appendixes/copy.tex new file mode 100644 index 0000000..6ee5ba8 --- /dev/null +++ b/submission_thesis/CH8_finish_appendixes/copy.tex @@ -0,0 +1,11 @@ + + +%% +%% CH8 finishing up and appendixes +%% + +\printglossary + + +\addcontentsline{toc}{chapter}{Glossary} + diff --git a/submission_thesis/Makefile b/submission_thesis/Makefile index 901fa9a..362639d 100644 --- a/submission_thesis/Makefile +++ b/submission_thesis/Makefile @@ -1,9 +1,10 @@ -CHAPTERS = CH1_introduction CH2_FMEA CH3_FMEA_criticism CH4_FMMD CH5_Examples CH6_Evaluation CH7_Conculsion +CHAPTERS = CH1_introduction CH2_FMEA CH3_FMEA_criticism CH4_FMMD CH5_Examples CH6_Evaluation CH7_Conculsion CH8_finish_appendixes all: ${CHAPTERS} pdflatex thesis + makeindex thesis.glo -s thesis.ist -t thesis.glg -o thesis.gls acroread thesis.pdf clean: @@ -35,3 +36,6 @@ CH7_Conculsion: cd $@; make copy +CH8_finsh_appendixes: + cd $@; make copy + diff --git a/submission_thesis/mybib.bib b/submission_thesis/mybib.bib index b818d6c..430fa1b 100644 --- a/submission_thesis/mybib.bib +++ b/submission_thesis/mybib.bib @@ -208,6 +208,15 @@ } +@book{DBLP:books/ph/KernighanR88, + author = {Brian W. Kernighan and + Dennis Ritchie}, + title = {The C Programming Language, Second Edition}, + publisher = {Prentice-Hall}, + year = {1988}, + isbn = {0-13-110370-9}, + bibsource = {DBLP, http://dblp.uni-trier.de} +} @BOOK{allfour, diff --git a/submission_thesis/style.tex b/submission_thesis/style.tex index a93d89f..c10b28a 100644 --- a/submission_thesis/style.tex +++ b/submission_thesis/style.tex @@ -15,6 +15,7 @@ \setlength{\textwidth}{160mm} \setlength{\textheight}{220mm} \setlength{\oddsidemargin}{0mm} \setlength{\evensidemargin}{0mm} % +\newcommand{\permil}{\ensuremath{0/{\!}_{00}}} \newcommand{\derivec}{{D}} \newcommand{\abslev}{\ensuremath{\alpha}} \newcommand{\oc}{\ensuremath{^{o}{C}}} diff --git a/submission_thesis/thesis.tex b/submission_thesis/thesis.tex index 23c4ca0..9d5b474 100644 --- a/submission_thesis/thesis.tex +++ b/submission_thesis/thesis.tex @@ -92,7 +92,13 @@ \chapter{Conclusion} \input{CH7_Conculsion/copy} -\appendix +\nocite{alggraph} +\nocite{ince} + +%%% ONLY NEEDED IF WE HAVE APPENDIXES +%\chapter{Conclusion} +%\input{CH8_finish_appendixes/copy} + %\chapter{FMMD tool : Design Issues} %