From b158fcb63647cb01ad2c91b31368fba88d504698 Mon Sep 17 00:00:00 2001
From: Robin Clark <R.P.Clark@brighton.ac.uk>
Date: Sun, 10 Mar 2013 15:01:29 +0000
Subject: [PATCH] C Garrett modifications to Software Chapter Just need to move
 analysis tables to the appendix.

---
 submission_thesis/CH5_Examples/eulerswhw.dia | Bin 1177 -> 1323 bytes
 submission_thesis/CH5_Examples/software.tex  |  69 ++++++++++++-------
 2 files changed, 44 insertions(+), 25 deletions(-)

diff --git a/submission_thesis/CH5_Examples/eulerswhw.dia b/submission_thesis/CH5_Examples/eulerswhw.dia
index 6a9f771ef12341ae25463efef5614419c2b628d5..f1c634a9ab9d130c2927ee5fcb62c90fdf840294 100644
GIT binary patch
literal 1323
zcmV+`1=RW<iwFP!000021MOSUj-xgdeV?yD%u6d}9ot~Qo6W3dx2oEQs?v7a*O3!E
zgf4*yoMiISZ?6sPBoLTnLY!_YkP->x+~aGG&#^D$!^h`&WUP3ag-JX%5rC$_<7wiD
zaWFRjeE9jDXMVi9`QV4_z5E0zn;Y^Mai-43=1hpi`{8iCUV~_pF_EMo3YQ?`!+%&5
zv7u}<H1BQ<V>f`$1XI__t4xSAoGb-5Vm9YvbHb)ygEU#jzFD*?+f9=wNsSeY#^&u)
zewf2D%&-#YmDmdw@JY(q*Y?m*9+aLEdco6r*!d#KLfJ%Y7JE%v;;8SPHf5_!Hj0D0
z+k5-A=u&xM8>^|Ktsr8~(jbiYapc%U#Xw--VT|Qq5b9Cr+AjJwCU1wETox|6EL?h7
zxG;NMB&kSQDE1*INfL1u7pNj#^3!p$DT^e<UQ4S(7EhrN$$|bqu_!wxf#UMZY<ug>
z4bsqmed1PHv_x5lzL-5eYZ|U1`bJaqRhWg7h&S~<jK$f)Z_X3Ges^;9-u}EJ8;WSH
z_TYP*aPoG02$rGGvja4%wrPnpE1L}uje5P^u>(_Fs+n~T5wQ(V%kZDJHf@wQxKtd2
zO+~o+cD6Gn$>eW76=kx22p0P+^^JGNr{vk(u0iAqB=pDT@31;p_4H&gse^l?wMe#<
zvVctn^4lWyLD-j&Hi*fjj*!Y6SR6!ri;{zkunk-?z)+%|hQ}j5f1D<1yuV5~XIeQ-
zE-3q{y@&|{n82L_cfgwQFqnyUFc(0Z?i}ukVA(8LKQ=5M4|`+tJRWXIdoqhrXBHF1
zFBedq943-X3dAEL<N;@ZsJ#7JN!%@~V<>C^RADgmG*TD=tAYjH{||+6X9`o`Iyt{6
z(#c{8g9;iuBa8u6n3BkjRw8%Kt>>~9E<f;Ru|sB5lG*A^W(N>y^HL@~om_rF!BA?l
zbV#gDC^=P@g&K|n3+Y;$w%eLl9xCl>MT##iHHudj_HDbwBo<9b>bmj7=3%sv9b$22
z8kyLr6{r-g;-|mxXvIZ1WxEUIxA$OgvNTK>2)ycqfp$00Dg%#Z;VDqn?anJTF$lW>
zu_z4UId8t7JYLSru{;u`aWnI_DY44CRG$>vu2>flB)h91$qk2N=S<LPt}iGU5oN9r
z74)OdH7L^kPoH~D(yd92MC>)`3N?vzUL?siIF|Y#_m!^J;!BBR1J@f#{y|$|66{`q
zCVl?x{^74)m9(#vnyJ|9()X-O&4mc3vn)ZNsBn6P_Bc_JC^^UodjpK*rcG-BqH9h^
zm4jX2>{e*0qqF{iWG=fJabjYVB=vcEC^ZOB34?435pvK4s?W72n;Na$J%^PK<Sn6C
zw~;Fp%NijH2vwU4xyf*^!N|Y#yNe6?_#O{?7r#Ci_qr;Q13WSyS|5l>2#Mg4k%fUZ
zz!rd7J-k~+#~3)4%ioHDQ=JCxzIbZsti6GsY~b_^25t|$lNo%hecJ>1A!L+4I+pgW
zo?KkT!wMV2Uwiw$fPL3l*qiqimIe_#!`lF!qx1pll_UvcJC;->iy{k+q=_Sh6)vK-
z=Y9Xe^h1_Bi8V|4kG(o+SEoi!_5yW{0)@^XP&D6ax{hXnq7JeY5F*G@0)?@vd#H+`
zO?!dr1?mtddx5$}fx>5a<AW4Ww20m}K8U6C$p)_F<gd3wCx;~#y#{%j$=lG&)1_Yh
h*k@#~PXDPo73cY1cJ6K}|LM8A`4<SM!RGfn006@0fieI9

literal 1177
zcmV;K1ZMjmiwFP!000021MON{kDE9ceV<=}nAg;?4d&7`sis}6b{|$Nb!Yc=WP*oy
zOCSO#nY{G3ueme{1ag6pHY<=43G2&u{F&o(Y?BWk-{!uuVo}V)V5}klRfPr9(B*+Q
zR{wtf^_``DoIHGRIejlbUPR}L{6!EacVl%X#Nz#MxL&V;zlo^`BjEETh}rNP^?f>&
zK|^)&peXwZTq<bNmbX$NBJL~&Qvy0?W7VP4uU-@`16R$W^0;Z}hmo?P{#bo{O)qtr
zrx_OV9Lc?)9&;i_zt*RQ^0MtFsTV9Nr=2gtn9C5cSsaAa<Vn8wV)Ce11_j>a@kxKo
zx|BEUa#eM-7DUWx<niDTM~;o34Fm=j##jypu`L^#x{1Dz$>ng)ZQ=ae!bP`*<MGQP
zj6_7aID~Y<&}THrP(`$4&2i!>^(DoQmDQq(S1v?&qW`bdkIyL}Yu?VbOJ}YZargMd
zEkx90S#wv+Ufwzyt}OeeqwFglbH`^@z2||rTKdg((wCo3s@}Vww`4<>t=1k~ixEaH
zw+C;@T^669Suv(2(<~1go*MOX+_?jjHI>Xdh4ATyMS1#9JDXPW2b?R8LZ^bSzTfSQ
zN$C8`rXnx)FF^yBMy~Qs`4qmXyETYhfpB-M{t1hNRW45^lR9`XT8nT;DGlgkAip(I
z9)v>)se^EwGD0M4pn>PJ9ZCu^!a6X?07Hq|43GJ2{xS`t;Bb|2&9YLMR8S5}+lmPS
zn83XYx4@b)?#)C!m<gb6?_Fj?uy_`(Un-W5r@gUy9uIe<ZOmfSn#CmHmkI1HIZPy(
z5)g}wkOhnZvgPCNl*H|-I)}m<Km`Uvt3wJSpcSy7`TwCXZcSkum`2Jk8+FNI34<~k
z8zYQ?onT5L8=Vrlb!|PDJK^#(dlP$PMmd?a)?_vSkv1=7((01STNDhXCQFCJ$&F2#
z%Cbm?<HSO`6jS$D)02lnT<MVFOU)U@k%fKTE-?&56;jf!ywW-MH?l)Ch*c#Pn`8wl
zMJxO1Z_HmY!KZY8p?rA{4kk;*gn_^+P8g`S11&P}Y!)_wDsFd<oQXl$4v6~P3+Al)
zd9q+R&&Tpil*-M_Wm966cBwomc3shKB1n2$L6RE|Lr<B|rMYfVFd~V$LX^?ZHts=@
zo__h<Yf{&mR7u2MlkQNHNb5zCT!Uk&4{~2=c6#`d<LJP&Mv{L}PcR8K??972|MB$v
zPp?Xyuav5(*z3~ItV`7g5k_lSf*_$n^Ap<hL`kBgAR}xIFp`_LP7fg3)^yf!unCO)
z6I$Eo^85kGTJ|-fVPQ@fxhy(W8U!eZLAnhQGSCf9pG$8xJG6518dg4#kHp4Z8+n4F
zX(MC<Vkesmxydl^!N|Y#yNet7_yG@l7r#Fjx7sR_0W2~goxTv05E8*6BMk#>fHeR+
z_3(BTonzowE`JLKZg*+m=GIelXYCEVv4PuHFmQcfHD>U+_N@=(hmcYF>R8%$^5)_$
rURLNB{@&a74eYzj!rr`psCj4i>0i1g4~74HO&<OOMKW|M7cKw*62v#m

diff --git a/submission_thesis/CH5_Examples/software.tex b/submission_thesis/CH5_Examples/software.tex
index 273b871..f74866c 100644
--- a/submission_thesis/CH5_Examples/software.tex
+++ b/submission_thesis/CH5_Examples/software.tex
@@ -30,8 +30,8 @@ Its outputs are the data it changes, or the hardware actions it performs.
 %% will react and how to interpret readings---but they do not
 %% always cover the failure modes of the hardware being interfaced too.
 %
-When we have analysed a software function---using failure conditions 
-of its inputs as failure modes---we can 
+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).
 
 %
@@ -47,8 +47,12 @@ and the subsequent hierarchy.
 With software already written, the hierarchies are given.
 %
 To apply FMMD to software, we collect the elements used by a software function, along with the function itself
-to form a {\fg}. When we have analysed the failure mode behaviour of this {\fg}
-and have its failure mode symptoms, we can create a {\dc}. That {\dc} can be 
+to form a {\fg}. 
+%
+When we have analysed the failure mode behaviour of this {\fg}
+and have its failure mode symptoms, we can create a {\dc}. 
+%
+That {\dc} can be 
 used by functions that call the function we have just analysed, until
 we form a complete failure mode hierarchy of the system under investigation.
 %                    map   the FMMD concepts of {\fms}, {\fgs} and {\dcs}
@@ -83,12 +87,14 @@ its failure modes and symptoms are.
 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'. 
+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.
+describe the failure mode behaviour of software functions, %.
+%We 
+and
+can use definitions from contract programming to assist. % here.
 
 \subsection{Contract programming description}
 
@@ -162,9 +168,14 @@ violations could simply occur.
 
 
 \paragraph{Mapping contract `invariant' violations to symptoms and failure modes.}
-
+Invariants are conditions that are considered to be relied on throughout the execution of
+a program. 
+%
+Here they are taken to mean invariants applying to data
+or conditions that the function under analysis deals with or could be affected by.
+%
 Invariants in contract programming may apply to inputs to the function (where violations can be considered {\fms} in FMMD terminology),
-and to outputs (where violations can be considered {failure modes} in FMMD terminology).
+and to outputs (where violations can be considered {\fms} in FMMD terminology).
 
 
 \subsection{Combined Hardware/Software FMMD}
@@ -207,7 +218,7 @@ and this is referred to as {\ft} signalling which has  intrinsic electrical  saf
 
 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
+The signal is locally driven through a load resistor, and then read into the micro-controller via
 an ADC and its multiplexer.
 With the voltage determined at the ADC, we read the intended quantitative
 value from the external equipment.
@@ -370,7 +381,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---from a programmatic perspective---%in software terms---the
+This software is above the ADC hardware in the conceptual call tree---from a programmatic perspective---%in software terms---the
 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.
@@ -447,7 +458,10 @@ With these failure modes, we can analyse our first functional group, see table~\
 
      5: $ADC_{LOW}$        &  output low   &       $LOW$              \\       
      6: $ADC_{HIGH}$      &  output high   &       $HIGH$                \\  \hline 
-     7:  post condition fails                 &  software fails              &          $V\_ERR$                  \\ \hline
+     %
+     % As Chris Garrett points out there is no software involved at this stage!
+     %7:  post condition fails                 &  software fails              &          $V\_ERR$                  \\ 
+     %                                         & \hline
  
 
 \hline
@@ -490,7 +504,7 @@ which we can call $ CHAN\_NO $.
 The reference voltage for the ADC has a 0.1\% accuracy requirement.
 %
 If the reference value is outside this, it is also a {\fm}
-of this function, which we can call $V\_REF$ (this failure mode is observable
+of this function, which we can call $V\_REF$ (this failure mode is detectable %observable
 only if we specifically use a test input to measure the reference).
 
 Taken as a component for use in FMEA/FMMD our function has
@@ -540,7 +554,8 @@ We analyse this hardware/software combined {\fg}.
 
      5: $CMATV_{LOW}$        &  output low   &       $LOW$              \\  \hline
      
-     6:  post condition fails                 &  software fails              &          $VV\_ERR$                  \\ \hline
+     6:  post condition fails                 &  software fails              &          $VV\_ERR$                  \\ 
+                                              &  C function: Read\_ADC                 &                                   \\ \hline
  
 \hline
 
@@ -675,7 +690,9 @@ as a hierarchical diagram, see figure~\ref{fig:eulerswhw}. % see figure~\ref{fig
 
 The {\dc} representing the {\ft} reader
 in software shows that by FMMD, we can integrate
-software and electro-mechanical FMMD models.
+software and electrical %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.
@@ -698,7 +715,9 @@ 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
+The unsolved symptoms, or undetectable
+%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.
@@ -773,7 +792,7 @@ start with a structured analysis `Yourdon' context diagram~\cite{Yourdon:1989:MS
 \end{figure}
 
 Using figure~\ref{fig:context_diagram_PID} we review the system in terms of its data flow, starting
-with the data sources ( the Pt100 inputs) and the data syncs (the heater output and the LED indicators).
+with the data sources ( the Pt100 inputs) and the data sinks (the heater output and the LED indicators).
 %
 We have two voltage inputs (see section~\ref{sec:Pt100}) from the Pt100 temperature sensor.
 For the Pt100 sensor, we will need to read the voltages it outputs and for this
@@ -812,7 +831,7 @@ and we therefore need to execute it at precise intervals determined by its propo
 %
 Most micro-controllers feature several general purpose timers~\cite{pic18f2523}.
 We can use an internal timer in conjunction with the monitor function
-to call the PID algorithm at a specified interval.
+to call the PID algorithm at a regular time interval. % specified interval.
 %
 \paragraph{Data flow model to programmatic call tree.}
 The Yourdon methodology also gives us a guide as to which software
@@ -874,7 +893,7 @@ Identified electronic components:
  \item HEATER --- Heating element, essentially a resistor.
  \item Pt100 --- Pt100 Temperature sensor, as analysed in section~\ref{sec:Pt100}.
  \item PWM --- Internal micro controller pulse width modulation module
- \item General Purpose I/O (GPIO) --- I/O used to source LED current
+ \item General Purpose I/O (GPIO) --- I/O used to drive LEDS %. %source LED current
  \item LEDs --- Indication LEDs via GPIO
  \item micro-controller --- the medium for running the software
 \end{itemize}
@@ -985,7 +1004,7 @@ This gives us a {\dc} which we call ReadPt100.
      FC4: $RADC_{LOW}$        & ADC may read      &      $VOLTAGE\_LOW$           \\  \hline
 
    FC5: post condition fails       & software failure     &      $VAL\_ERR$             \\ 
-     in function read\_ADC         &                      &                              \\ \hline
+     in function read\_ADC         &        read\_ADC     &                              \\ \hline
 
 \end{tabular}
 \end{table}
@@ -1060,7 +1079,7 @@ We can call the resulting {\dc} Get\_Temperature.
                                           & incorrect temperature     &    \\ \hline
 
   FC5: post condition fails                  & software failure     &    temp\_incorrect               \\ 
-     in function convert\_ADC\_to\_T         &                      &                              \\ \hline
+     in function convert\_ADC\_to\_T         &   convert\_ADC\_to\_T   &                              \\ \hline
 
                                          \hline
      
@@ -1111,8 +1130,8 @@ an incorrect error value.
                                         &  unobservable                    &                 \\ 
                                         &  undetectable failure mode          &        \\ \hline     
 
-       FC3: post condition fails                  & software failure     &    IncorrectErrorValue               \\ 
-     in function determine\_set\_point\_error         &                      &                              \\ \hline                     
+       FC3: post condition fails                  & software failure                          &    IncorrectErrorValue               \\ 
+     in function determine\_set\_point\_error     & determine\_set\_point\_error              &                              \\ \hline                     
                                          
      
 \end{tabular}
@@ -1177,7 +1196,7 @@ being the logic and process  of the failure mode analysis.
                                          
       
        FC3: post condition fails                  & software failure     &    IncorrectControlErrorV               \\ 
-     in function PID                            &                      &                              \\ \hline                     
+     in function PID                            &           PID            &                              \\ \hline                     
                                                       
      
 \end{tabular}