From 3607ac6c65065f090bc56cabc8733f53001ca4be Mon Sep 17 00:00:00 2001
From: Robin Clark <r.clark@energytechnologycontrol.com>
Date: Tue, 31 May 2011 20:35:31 +0100
Subject: [PATCH] OK another night at work...after work

---
 fmmd_concept/System_safety_2011/Makefile      |  14 +
 fmmd_concept/System_safety_2011/component.dia | Bin 0 -> 1240 bytes
 .../System_safety_2011/fmmd_env_op_uml.dia    | Bin 0 -> 2324 bytes
 .../System_safety_2011/master_uml.dia         | Bin 0 -> 3529 bytes
 .../System_safety_2011/submission.tex         | 410 ++++++++++++++----
 fmmd_concept/fmmd_concept.tex                 | 120 ++---
 6 files changed, 389 insertions(+), 155 deletions(-)
 create mode 100644 fmmd_concept/System_safety_2011/Makefile
 create mode 100644 fmmd_concept/System_safety_2011/component.dia
 create mode 100644 fmmd_concept/System_safety_2011/fmmd_env_op_uml.dia
 create mode 100644 fmmd_concept/System_safety_2011/master_uml.dia

diff --git a/fmmd_concept/System_safety_2011/Makefile b/fmmd_concept/System_safety_2011/Makefile
new file mode 100644
index 0000000..84e34c3
--- /dev/null
+++ b/fmmd_concept/System_safety_2011/Makefile
@@ -0,0 +1,14 @@
+
+DIAPNG=component.png  fmmd_env_op_uml.png  master_uml.png
+
+
+%.png:%.dia
+	dia -t png $<
+
+all: $(DIAPNG)
+	pdflatex submission
+	acroread submission.pdf
+
+
+bib:
+	bibtex submission
diff --git a/fmmd_concept/System_safety_2011/component.dia b/fmmd_concept/System_safety_2011/component.dia
new file mode 100644
index 0000000000000000000000000000000000000000..4ff70014fce026d523c98de0a5bd1e9fdc18de52
GIT binary patch
literal 1240
zcmV;}1Sk6+iwFP!000021MON%v!XZ@-rrwAad%U<BMAgT+uAj~n3}~@&7ynOR+Nb8
z#$Z9z>t=rYgomy2@B!kqRZyk(f`{|v9KL)xN%-{neHmyQ7R5XiBOL-m*O-`v9vA*d
z|L5BuABg^W{PM};^rQOt5nXEP4iP73BYh#|>f>Or-EKj!i>VAF5b!mK+2CIq1azQ`
z2Kx9#(~cc@RMO;Hew9iY@#$JJP0%G9=~FuU;YZ<GczR})+s(otjI<36M*8bKJ@i5D
zW^m%?jPDio*)(GGN4;x99j@EN^@>GBx64%+b7dlTtCC5LpXB?<Cbx=}k?_Z_zgw?a
zlky7(UsVmQ1(8b{`COE7RBnPS5eN{3kV*!2iEB8P1NS+(9d7zqxZtsH(PQCwJXwX2
zj3}37$Y~e`jEW3ZMr+m_C!WzjQS4k;EuxrnDZ>lxpVJ_|CV=en&)#-x&-Ekjo$t6O
z7BybB+>?vRdq?TYyze^lzTq*S2CS;}T*$k*-`&T3@#&=MeYm|P8!~UT!-Gc{X888u
z!C!Na#TRIHYE$EBk(&)JWxZ&3ZDO)Zg~2+72<VPQx%)4NVOq-{aIQESok_mgpB?2S
zoPK9BnFsq-QsL3a(>`cl!gu{pgQyCGdn5gC<1|^t@RT#9gQaY(!k?5vz<EQ!c5pET
zWdW%Jm`;oSBNYJ^e!%t^Hcmhg9zp|{Zx$d;@mRo?lUW#va*c4mpi+=jOv-`ng~S0E
z8%GDUTVO31_ZPAr3;}4lM~8`;fyIk(JE<rgFOQ4WeRyyn>=g|D#@^)-g<(!%*p|XB
zz=~1^>XO0<h6yZln1Mm3DYs;jgbP|-u&H~PX>ogESEz$)s^Bw2M_nBf3Rwk|T-WAw
z$%CD04;8Vl#d4QuoYJT4)<0RWVUo}2u@v9lf>IBu=p_aq#_3_T13jhPmDFnjbUK`#
znR6LNJ0Ml8`eMndpC%LQWuD0^Q7Q+^+xo*MZBnsE9GYT2M1xRU4T3gs5`}O(9Z2^m
zCK+b`DkVa_67@<{L%?2(o=}U-)>?#tO;R!t+-XsC07BSNwS9i721KLRq+XM1iP+21
z6Uvg+R+exwA%C+v)T0bRP16jl=4r^y3Z%vw_((BI{R+jpUX{95r4kQ&IeJ1l!tLeA
zNERhgrxUgm1gcSRXah)40%$$Ogbf1lTQ5c3OHrAFy&C<>YE-=oW8Y!<$RJ86u+{PM
zkzpzn%f&;4fs5WSKwa*`v<~Z<ofsE5<al$$g&pq1n7}rUw_=F>j5{%ZaltBR?6jt_
zp{i~dsuJ9`OwuWp6_VwUbWg@K?P1C^<Rr*0Mh!_l3x$|4;iVBZinF>4n9xibN-W20
z)-a`JvsJM@Rc{5HbDBh_lBk||Tq+{=zi11^k$eD_VY<Jp9ey3@q!en!y)eJmuDy4!
z`-KMGr!pjWU@=K%j@_1q8H$<Ih7hI;XbSR4io?D#?0o60ii3S=_=FQxx3wHu0NaUD
zG+tG|PLDDeH9>{xO1_&er9s@!R(nl4N5o!~o=}uv>-PpB0T`w4B3Rv)Nf{0Tj`}l1
z2#`#eo<No6ln3jGY0J=KaW7Au%TqNYdwu#}^(i|~--#Z-oV+wWe)$j6aue-XH2?ra
CLsoA9

literal 0
HcmV?d00001

diff --git a/fmmd_concept/System_safety_2011/fmmd_env_op_uml.dia b/fmmd_concept/System_safety_2011/fmmd_env_op_uml.dia
new file mode 100644
index 0000000000000000000000000000000000000000..6225a05ba65f03255ab602fb3396e6dcc90afb6e
GIT binary patch
literal 2324
zcmV+v3G4PBiwFP!000021MOW~Z{s!=e$THkJa0ux^M0wC6x+otwm>@r>`V*vDNt<1
z(N>lWSxF`@{q0Lqa^j1WIHH-1W~m^7<xu=Y>gYR%ho7h)fBLe>Mz=}1N{jq#i~t;u
zl6+ds(tLh4{{8d6zL(>l&QE@vrST8?cV5Pekv<|{nZ2{|byY2Ym`v{O?m%|GimRdo
zS$YFj$>i@i%i@VHG#Q_tj7FOk%;G9G-!<RHRaK^!H&rsq<3(~dzKo}T&CB8@pN;EM
zO}S~273JtQ&d$c~uIx6RG}TPD>UpB>Wjs$V%Ow7*yK1O6rTSF8Ov>GA7t3Om>LS(s
za<527J?8I5nWofA7s}`7@BTsG)u+^a@mN>eiFSfii@2Pp`96;Bo2>2#3?#-_cLq~Z
zK|uvt_sPrQE?*ZedtJElb>Y(0#j+@?GES>~$jhS0k~ptXtMVr4kF%P_nKrSfn&r@n
ztF)?$XU_jB&Q^ysp#J*dZhPsSJ1^7O(>Lx`iH=(C(phzV@x@bj)wSPys{J-yrI%UK
zcJ^sr9j*HN<5a(Ubu4>79`0xjb#0yQVI~unu$Q}s`As@YR?nE(cA1WvuA5?$=X!m&
z+@T#)f3@SREkqXICuLLp&yQ|;)Lh_(aYpg9N^jSD8+}q-{x_LcO=CY*aXyR7+35Sx
z&&8MVV+^7rkaTu7{s^}_Yqxp2GR=c~y|pYJOiBUFP7wlZw+r?OqzmBka<~3cw;;~v
zS@M8kASjCv2U5ckAo{^2S+cm87G=I4A{?(x7Q}MNe!JE@A^>A>V?*2l>pDs2*Ht$d
z28gPSjo^M@tLx(Kq9t;C-YvG@!jngPJ-~oJCts=!3r39vBUcO7HU;(N*3pAc8-75+
zB6|3&r09uRna+5IvUkdKT~r(6Zk5{!hdYAdCp<`3I8x+Q8<6>abQLes>|UQwoUg{C
zRdsKuPSaF<=)aTfHmTBSyvfKfKZCtHrR8pcK*H^fx`A$+-@zu>2Ws1|J~8-$&<#jO
zt@C`5v|rC8zgaYWc_2!w*L>L>acfU$_nvq>74j-<gk9MP6F{sbc;uor2FB6)qauNc
z0u!~GU*Mqu@(^+6Ax#gO6O1izA$&$g8%R(I7H#ZH6i6wMQnxJzYWkX~sXgOBkCJiV
z0Qt^1Xb3Y>({`u4CmZ@V=dff0-AXnP;WgQ?%@2Ju8((FzfjK7|5J0B_`1Pm_2vRIU
z3~<WyjzV|<zVzxQpH{lZwK18?z6`$Ad+MRZAcI>So?GSaZWZYW3sA3K6=?**8n;T_
zoZbPR)uly!viQ)iW94dV6W@?y70!+o0;U5g0-#sVTBBe<g>kKl8$>jSEdDGh)7xY=
zvi0YhKZ9@e?pxbzGC0=(rqiS|J(+BKozucz3F-j{QycvgWz+k72+@C_rq`pUc6$uu
zG`z@P9U;|^PMP1pNn=2E$|3@dfX8b>&9OO$#QkzN6ek|zegae{ISgOD1CKCaE=&T|
z^Mtv@FcaniNQzBHO$=hn{C$3#mW8FwI6L`gk<U_-U|R(j`wCO(yM`Iu>(}gFe@*kG
z#lIqVg(1^qVFGcZVTH(N_|E|6lAlT-IAYw)r6a_xmKCv{eq&nX`9+e?Y=e3=v(-mK
z28BLPiMi_8Biat8%iZ&7)4D%ZscBte=NwjhjJ*EO=vv!I!(3HiRnw!#|LSmHuc<A^
zqUKoDdF=X***T%31c}I5m`02;NRJwPMu{53X4h~;5x_c#<30mL#}*xyAeP%QZ|XHr
zB-<{Id`p3%v!aPGz|5?JPy4MQ2%y@6A)w-v4n$e`>CaD}-~V><{=*-?{O99`-`;=t
zJPHw_?+9_<B13>U!~oG*(o|<fO!!27Mu!?kNQn(8NhBlV{}2)eSFygci3dlA?QLxJ
z%9tu?GB}iQF|^Q7IfRBfNb?&TcKKFkSrZXDl<NId-eJaDLm(VApJaGsA$ZYN+Y4TF
zc(WMDS-_;@ZQrtB2#D3{Mzt*1vwq2~L5B=aIl$ZV7}BeLNo|XzzNx2>odrxL5pgQa
zfWYTOMlCj1ibZ<tVZ<pCut6w;KQ5CpuBE{z`f^lBn8ENrgVAD=!M6@^gzBtc(hiR*
zCXF>{^6;5M<7RFhStP7Djm+~gka4}wsZze@Fgn}W`rr<Pdibo1%HEUmZ#PiY0ayQ#
zD)l^2?XqKMtqURmA|mY^6;;Bo5>FASw1ZVt5*`_3PKlk1>mB<XJ{Q;3&Q>Xyl8TxW
zRZ{Z*r@6Q{GGh#nASYFtpv>?9LZbYdv6Kp(QUI00%9=5P^}q!7ow+^SjJw*|UX&<q
zo+_bz$1!hb#ni!y`P*a-v9m6MVDsFWzG7bUhHDU$IV1oP{c#wnLlj0h-gAd778pi2
zLtJ;sUEhKLw0b?S0+$+u0j0?Z0b;W;d=PB(U0@^cY}8_cfsKa9M()cmAsw&S?5x*x
zaE&5>5|RFF*4UAN%Rongj=F3x@X-+Yh`Q&0mF5YrX<ubLAH|UX*eqTXf}+4eZI%}Z
zXov)KjD@r8b1ca3x>*{-EZPtu44B2k!$=hY5UA)i*2>zo!N5jCWFvkAHnIXR;+Ku=
zcuZ(EYT#&)yapm_H@`qcLnI<`l(0wv&U}YO3P90BMG6QRf}+4hofa6lXn6X2ERV2^
z5GUFa6!yE05R)22iint17|pxDdP}AcUQfuWU55zq4W(`g@sZc(#5vr2ADA5E3f*1W
zDs_bSfk~>6SsRToi2c43Oek(8fr>*CSxckXAk)4N?;kF$>S|`|9l#{A?}dS=@5|$c
zsSwn(_$J~i;w}*sfEsr6nlQ5%*e1+`9+KEsGvXkw3Xx%l1%}9Qi0_g@$51mM`$|<w
zJj)qs7;Il7WyCbrw}#Pb;H0N4G0@TwY03Rvo2;e?43O};uGtz00j3N!NuZF$C1?Qe
z<cZVlrc6eQViq2{eFcW<Fv`GDL*yuDAt<6Ih^Agu={1H~XBwl(U@2xXxghlG=O++2
u$@@rd-w3_Y5sJ-EprfbhsNT=w`=mTSsdx16yo?v;C;tO_8B#=Vi~s;}F@Q?|

literal 0
HcmV?d00001

diff --git a/fmmd_concept/System_safety_2011/master_uml.dia b/fmmd_concept/System_safety_2011/master_uml.dia
new file mode 100644
index 0000000000000000000000000000000000000000..6775a9730bca039d98284e5d6dc617f95af4ed0f
GIT binary patch
literal 3529
zcmV;)4L0&0iwFP!000021MOW~Z{s!=exF}qc-|HXLmuAi&J=BTySu<HTA<zMK(RHB
zwvHUgN@nu1zkPWqWs=xZE~e;21E!cM>{0ZI(x>lSczF2z4__`;lk2?N6zlTClo2|e
z<mG(5D9YuB>3{zC<=9Mr`1tPoMUj2y{w%BPV&Z<I+~B7V)APE%{O;uB^XJcGb+gIp
zbwyUi71`t`|I1dZ?8F^(GX3~&GP!?(MOJ6{UHffT*Hv+LRp*m3yU0IG&$9WS%W8d9
zE~d><?Q!$<YF$mPv(<;``%nI7deWZe<iU9!Irn9@%+IPk`?LSl)cshy&#5o-YWuVo
zm+MX84ykW0cMj<}5B`1cnD(fRJE&ZKeE*|(-&|7r#of8OF0>b<zR0R&QSRcnd$Ve8
z1P}uN?q*19EY(7@+k5hIxU<8;tqu!U9Tu+GoL;W0y2^@r7xHYqUgcTYpw`t@zCX@p
zo~<0k9vfD`C_WW+y?)~QKV_@Ua|Y0S{q=2o>6^Q(ipAqE?t>$G&hoif)aR#PBHga$
z>^G6leqC&evsK=8^+j0^cKVxPPQU$hyn5gLdLSE`v-O&Xg~??uUv3_jSH&XVJVCRE
z$Ml@(yglsXsk^>?+;eYC^VOEI_7JP=Ca>Dl|8!@jC+!1n6=#yo>*D(M)4hALKKpMz
zuiL@?UT5VZs}_^v$xrJq(>ou;c_78&!}M4B@Mdif&z;Qa;LhE;Tz{n$5P75s-@XC6
z^3iwtv$O59SMK_=a=FTH5d=bjoH0t^$P%?5SiZ_HPUq{Y+;tCz8jpwYDzZDKTLsZX
zNqYZB1Yn)##qzxF2jc{Uz5m1Z1KXUhKc9B^j87ZH?w9xEj;VW7mxWT7x#x@zTSO!;
zVj!R73<ROlv6l-OlfQw3dUFhRPMy6^VWY>$;6L&&^*su+mckH9VL^nJM}|<45lP&j
zXd;B1X`&4vBvboh)_60Xa5uJ&>3gU?K6`N7Rw(x~p0~`)x+kK0#0~26sn=!Qg^1rz
zK4llh>c(AIR&J(~O?`v*+6h+ktN+MX*Lhvcv-@tv%dcSPmFakGC^3}wy`=kqKIGxE
zxwsG1L+9|33<9NLKrZxJmKS;V^UTYui}qeV6Q$Gjd)cdT?JsHj<+!^Peh^vW!Isq!
z@QPs|rft1N0Wkw0)Dh2puu_jemww5L)m4>G{=Hu0Nt$9yQzsvjG`(eM`d3lr9ZtUp
zmL^J=mx-tzlS84_D$h7g^~`(aR3NUF-0p`wUzg=+UM~D-UOdL`Pyw${Yq4iY?H>O8
za{EHMvQ3Yj6o=*Ro_oxj9r3;Wm&v&!Mk`qL+UG4McmL{qkDYOL{4Q&Mmp%Mlvzxrx
zx}agKsvLm2LQ>`)8IR0e52J|Im~t^xBBn57u&XQ?)9A*ulZMHfj?mFp!IC6MlNpFA
zNFGEvLpAeeO^!l|{*sg^x)OD;FX_-*)}ii9z7Cb4V{}s#X1#4h9YPd~evuHfV@{Yl
zvPAHx+5F&vrF?#re11=KYJ!Q(37}_XxsGX35k^tQeDo)bodJ=u`RpEuVv*z1?ooEn
z#Rf#`uNR%_far89vgHSgPHixCEdk^6|0XVX8yx2bQY~l4iYRcPFowyf-?FOSIPKV^
z*{JBgVGkXXdpN={mC*t0DmoppBh_0NAFHB^D1;qNz?xEL@kObVhDnpgs7c}FXM{Fs
z)VRsB2E{895XwB_NCb(Hlthc4MC+nqlBDrv(HMl+a&zmba7@X*6T;6d=;oq<k!<E?
z%H1a*!pOLV-Jyd^xwJ#p#<Jilv}5-$xO2c+^pr#kMBAJM5Z&O8A}jIBRq4}7j#Ynm
z&;K%++~{FI4>6O~9brWp3oc1h1gsIpuW_PLg-Q`-3>9c>x!`uDoF%q^^GlpEDI%x+
zd&k*%C^v>TUI8;BuTC>Bs!oH~DNkcE+<i3mNa8AhsLrDU5$-QJ<HSgZrx>JQHd)qQ
z3MQ*M!dO-fu(%U$qf8lhfhTL@N;Lyctnk6CG_hBChK}wHu2rVyK{N~BQZ%avAhcnU
zxu8MDjb`tFC`PjYSb^a=JqA1b*SspO^Tp);0;_k)@J7!f_pmb=-!aZ@1=q0wbrGer
zPb_96&|**`VD=S|Fg}L4t)xiNLxEiiCNUage$5UbM$}S?9*nkB#g!z=t@gf>0fnjr
zlwropIqRS!=hu42*?A~h>t<Ez=+bL0It<9Ky-s=!Xn2~~*rQ|Tl}AnyHz-PCuNM#!
zV@%6a0b4SveH=_?b%Z`XumPI97_1yZv54E{rGWv$%#2yWXag!n(SRx?{SVRIrGtn`
zmByF$hXG31B+7#&Dso3s4<ehMr1*hh9cARkq(LKlX1@PHw@?!^-|rNh4l%j#Haj~8
zSFdpwIwG%V+-@%|jKyXz8hfZIgd9h+msNh9uO{D3+&#;ed6g_}Y)jkC$z*BA=>Lmw
zf#R|u14Pv)-q>0NvpYndlKe@K`Z$>MXpDLk-X2d9MGw#(uZ3ya<9)>(hsTr@DS9%Z
zlZ8o=MwpCH1GGe;e*Q#2<c=uKx;9*U#BlouAh37WoM$$s3Le@UTurBxzE^-~_Dr;#
zt*b>|JvB6nd2Ii~gr$rrc7Srnt-ZctnsXhV$#WFOdL9vXIRT<jB9)vOq8K8A8B?KS
z+Tr4Ws|z|PnN0f#i;5t;Qy(M3>4uHHw3y*sgTyLFBMoph^Xu4^Mr^CCfY`nII>*_$
zyk1bI@KB)zjIO2#R7gkpS6Z_Nc8G?P>WD`!Dr!)G2<unJW04xRfP_?3l+0=m2a{PH
z<Hk`myeXE(J{tSi_B^vGmP2vDD`U983H>>Tsgf8aG3q8@5~H^)M!&6BH_LU|;pX%3
zB1cP<IKpMUao1d0%s@CCV^NVP(F|J~fZiAN(%qBOr#Fh~99`#ff#)8_gu8CG_uYEk
zVxC8s6kM4mov=uM52Knk2Lql*AZOV0(X$AmvZ#AxUB%<iJr1n&ECTrrZ4SW08=3*`
zZfP)*0wb-88?jMP(oZEY4SL3j;>J-+5e}5aZWYu&(ykf+sVU{Yt<c`d;<uA{Faetd
z44!xRv6^==d5D%*%qO+1iQVu@T3oW?LQK%oqG@H|$ifH}pjrHmS6##GUb?4bP(P3P
zRdt=8E{csC|2*%XcyhObJLi^zRUC}76Kc<Oi7O{_(Pp{!TNel+>jJmlLpJog)IH10
z<p7yzit|=Zp)H8GxoAgH4<tZ1??M^($^DOO5qA@$@ByaYtx;T^9!{$vHuSR1GdChK
zsU1?oYVFuH^LrC{T5A)V)&q<&@%oUfI=CL9BnY3m#DYN)w<yR131X=hxKENX2&-V<
zt>g}w==}X=Q|A{c+j)Rpk~-;_5}sq6eF-jVz)laI4G>qHS{y+%YLg(6dkT(1n*LT^
z7uDMHFX>Zked-}(lBW^YT=DQ?6`YszaUjHv39ufNYAyXzGtJZtk*Nh}qEOAFS6y|F
zwDUme*FTB9Z%J6{a~N(2IsiAM5-x=E&rHd<^iUie){!B~02R1>F4LU*=fI=)`RX5P
zS6QAARta~dT3F3T%n&w6satDItc^Q&!kK$<5sDeyEF2S9T>3A#V29XVxoe=^nKj2G
z;g97~jcx9PhZJpc8F})gkI68=#zs_QIN#)~;_ht3z%qSg2{%Fk<`JxwhPPQO6PwC?
zBkexaU7@>D!R6SA{Gyo){W`_Rf)6lr0ZjswMNWpbKtPmFhJ8)>@==7GsfSqnL|6|M
zQ=~b<M3@M!PdGMBUX(^xrUuBi!la4v{g=j}OQ{?=zAp6;G3nA6bt$~oLlNWiLLzbo
ztib_4GmTEaq~176X_GD`UFs!blBMzWIT30AZwU)oj&U1NEp1$P2_rW|l332!y6wkK
znJlF?YPrr3gG^0NzU8JTLJ#mJG32)(QbFuD$s;w(EG#a|HX1y%`%Fh*<$t}*tE}C)
z+&!B*-z2ktfN-RnpULo#a7JE)cR`V)UA2I#D`M{UcHC_AY|z##DVdqMZ-m6T3E%om
zX&HUqwQsQ9hbpGMXQJpUO-Kx6)a(F3YqNicg~;Av1LT}R>YYPLv_f3Hzi*h*{NGyG
z+DXM^zQz}~N;<?I;n1vSioHd+_SrKl{TAVX%S)t<y+L@`(9+71L#`~5;hicp@(YWq
zA#R6(TOh|R7X#pmTGcEeVCL=H*ngJi#aU6m`*~e13SSbDjBfOnIz7xxMt6iUqlECa
z|H^P^6ay?oUHz{(XAF_3<TGy*nf1Whis)<qdxqI*teIwhc^;$t)|S6w@tO=MUX%27
zsxT!VVq0mAbn=cJMBY{!a1R`?ylG)!ZR6W1c7Q#lI|td*{K?>Dav`)G8;c(y;+x%6
zS_T(7X+oQocro)bUqLwFp3=sPA|1sRPAMl7-97B0U~&ydSl%Ru*uqJe=yG(2;`GRU
z&^!rJ5~L?sm=tM@ilhc`@;w)vZ!6<^_y}W()V}*G_mE(cA|*xYWnq$}F-npipe427
z&FZzd9jQGE5bc~K+w}V5?z<#ONs{_lm=tM@ie$of0=Gww4^g+>^%#a|32Y_^wNePg
zl)%N?*CUejDE?01I~<IrMl8esk{Ug(M$P9{c9T~h-!&iHpJkO@e0=wR(M`1766F8@
D&r$xr

literal 0
HcmV?d00001

diff --git a/fmmd_concept/System_safety_2011/submission.tex b/fmmd_concept/System_safety_2011/submission.tex
index 19d04be..f321630 100644
--- a/fmmd_concept/System_safety_2011/submission.tex
+++ b/fmmd_concept/System_safety_2011/submission.tex
@@ -37,25 +37,19 @@ failure mode of the component or sub-system}}}
 \newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}}
 \newcommand{\bcfm}{base~component~failure~mode}
 
-%\newtheorem{definition}{Definition:}
-
 \begin{document}
 \pagestyle{fancy}
 \fancyhf{}
-%\renewcommand{\chaptermark}[1]{\markboth{ \emph{#1}}{}}
 \fancyhead[LO]{}
 \fancyhead[RE]{\leftmark}
-%\fancyfoot[LE,RO]{\thepage}
+
 \cfoot{Page \thepage\ of \pageref{LastPage}}
 \rfoot{\today}
 \lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
-
-%\outerhead{{\small\bf Developing a rigorous bottom-up modular static failure mode modelling methodology}}
-%\innerfoot{{\small\bf R.P. Clark } }   
-                                              % numbers at outer edges
+                                   % numbers at outer edges
 \pagenumbering{arabic}                        % Arabic page numbers hereafter
-\author{R.P.Clark$^\star$ , Andrew~Fish$^\dagger$ , John~Howse$^\dagger$ , Chris Garret$^\dagger$ \\
-        $^\star${\em Energy Technology Control, Lewes,UK} \and $^\dagger${\em University of Brighton, UK}
+\author{R.P.Clark$^\star$ , Andrew~Fish$^\dagger$ , John~Howse$^\dagger$ , Chris Garret$^\dagger$ \\     
+         $^\star${\em Energy Technology Control, 25 North Street, Lewes, BN7 2PE, UK} \and $^\dagger${\em University of Brighton, UK} 
 }
 
 \title{Developing a rigorous bottom-up modular static failure mode modelling methodology}
@@ -71,34 +65,6 @@ improve the product safety, or identify theoretical weaknesses in the design.
 This paper proposes a new theoretical methodology for creating failure mode models of safety critical systems.
 It has a common notation for mechanical, electronic and software domains and is modular and hierarchical.
 These properties provide advantages in rigour and efficiency when compared to current methodologies.
-% This paper proposes a methodology for
-% creating failure mode models of safety critical systems, which
-% has a common notation
-% for mechanical, electronic and software domains and applies an
-% incremental and rigorous approach.
-% 
-% The four main static failure mode analysis methodologies were examined and 
-% in the context of newer European safety standards, assessed.
-% Some of the deficiencies identified in these methodologies led to
-% a wish list for a more rigorous methodology.
-% %%
-%% What I have found
-%%
-% From the wish list 
-% %and considering some constraints determined from
-% %the evaluation of the four established methodologies, 
-% a new
-% methodology is developed and proposed. 
-% This has been named Failure Mode Modular De-Composition (FMMD).
-% 
-% %% Sell it
-% %%
-% In addition to addressing the traditional weaknesses of
-% Fault Tree Analysis (FTA), Fault Mode Effects Analysis (FMEA), Failure Mode Effects Criticality Analysis (FMECA)
-% and Failure Mode Effects and Diagnostic Analysis (FMEDA), FMMD provides the means to model multiple failure mode scenarios 
-% as specified in newer European Safety Standards \cite{en298}.
-% The proposed methodology is bottom-up and can guarantee to leave no component failure mode un-handled. 
-% It is also modular, meaning that the results of analysed components may be re-used in other projects.
 }
 
 \section{Introduction}
@@ -139,7 +105,7 @@ analyse how particular components may fail.
 FMECA is a refinement of FMEA, using 
 two extra variables: the probability of a component failure mode occurring 
 and the probability that this will cause a top level failure, and the perceived 
-criticality. It gives better estimations of product reliability/safety and the 
+criticallity. It gives better estimations of product reliability/safety and the 
 occurrence of particular system failure modes than FMEA but has similar deficiencies.
 
 
@@ -156,20 +122,23 @@ via self checking statistical mitigation.
 
 \subsection{Summary of Defeciencies in Current Methods}
 
-\paragraph{Top Down approach} The top down technique FTA, introduces the possibility of missing base component
-level failure modes~\cite{faa}[Ch.9]. Also one FTA treee is drawn for each top level
-event, leading to repreated work, with limitied ability for cross checking/model validation.
+\subsubsection{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component
+level failure modes~\cite{faa}[Ch.9]. Also one FTA tree is drawn for each top level
+event, leading to repeated work, with limited ability for cross checking/model validation.
+
+\subsubsection{Bottom-up approach: FMEA, FMECA, FMEDA}
 
 \paragraph{State Explosion problem}
 The bottom -up techniques all suffer from a problem of state explosion.
 To perform the analysis rigorously, we need to consider the effect
-of a component failure agiaist all other components. Adding environmental
+of a component failure against all other components. Adding environmental
 and operational states further increases this effect.
 
- Let N be the number of components in our system, and K be the average number of component failure modes
-(ways in which a base~component can fail). The total number of base component failure modes
+Let N be the number of components in our system, and K be the average number of component failure modes
+(ways in which a component can fail). The total number of base component failure modes
 is $N \times K$. To examine the effect that one failure mode has on all 
-the other components\footnote{A base component failure will typically affect the sub-system
+the other components\footnote{A %base 
+component failure will typically affect the sub-system
 it is part of, and create a failure effect at the SYSTEM level.}
 will be $(N-1) \times N \times K$, in effect a very large set cross product.
 If $E$ is the number of environmental conditions to consider
@@ -186,96 +155,347 @@ To look in detail at a half of a million test cases is obviously impractical.
 % Requirements for an improved methodology The deficiencies identified in the 
 % current methodologies are used to establish criteria for an improved methodology.
 
-\paragraph{Reasoning distance - complexity and reachability}
+\paragraph{Reasoning distance - complexity and reach-ability.}
 Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
 working heuristically. A base component failure will typically 
 be conceptually removed by several stages from a top level event.
-The `reasoning~distance' $R_D$ can be calculated by summing the number of components
-involved, multiplied by the number of failure modes in each component,
+The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
 that must interact to reach the top level event.
 Where $C$ represents the set of components in a failure mode causation chain,
 $c_i$ represents a component in $C$ and
 the function $fm$ returns the  failure modes for a given component, equation
-\ref{eqn:complexity}, returns a value representing the complexity
-from the base component failure to the SYSTEM level event.
+\ref{eqn:complexity}, returns the `reasoning~distance'.
 \begin{equation}
 R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
 \label{eqn:complexity} 
 \end{equation}
 
+The reasoning distance is a value representing the number of failure modes
+to consider to rigorously determine the causation chain
+from the base component failure to the SYSTEM level event.
+
+The reasoning distance serves to show that when the causes of a top level
+event are completely determined, a large amount of work not
+typical of heuristic or intuitive interpretation is required.
 % could have a chapter on this.
 % take a circuit or system and follow all the interactions
 % to the components that cause the system level event.
 
 \paragraph{Multiple Events from one base component failure mode}
-A base component failure may mpotentially cause more than one
+A base component failure may potentially cause more than one
 SYSTEM level failure mode.
-It could be possible to identify one top level event asssociated with
+It could be possible to identify one top level event associated with
 a {\bcfm} and not investigate other possibilities. 
  
-\section{Requirements for a new static failure mode Analysis methodology}
+%\section{Requirements for a new static failure mode Analysis methodology}
 
-A new methodology must ensure that it represents all component failure modes and it therefore should be bottom-up, 
-starting with individual component failure modes. 
-
-In order to control the state explosion problem, the process must be modular
-and deal with small groups of components. The design process follows this 
-rationale, sub-systems are build to perform often basic functions from base components.
-We can term these small groups {\fgs}.
-
-Components should be collected
-into small functional groups to enable the examination of the effect of a
-component failure mode on the other components in the group.
-Once we have the failure modes, or symptoms of failure of a {\fg}
-it can now be considered as `derived component' with a known set 
-of failure symptoms. We can use this `derived component' to build higher level 
-functional groups.
-
-This helps with the reasoning distance problem,
-because we can trace failure modes back through complex interactions and have a structure to
-base our reasoning on, at each stage.
+\section{A wish list for a failure mode methodology}
+From the deficiencies outlined above, we can form a wish list for a better methodology.
+{ \small
+\begin{itemize}
+\item It must address the state explosion problem.
+\item It must ensure that all component failure modes be considered in the model.
+\item It should be easy to integrate mechanical, electronic and software models \cite{sccs}[pp.287].
+\item It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
+\item It should have a formal basis, that is to say, be able to produce mathematical traceability
+for its results, such as  error causation trees.%, reliability and safety statistics.
+\item It should be easy to use, ideally using a 
+graphical syntax (as opposed to a formal symbolic/mathematical text based language).
+\item From the top down, the failure mode model should follow a logical de-composition of the functionality
+to smaller and smaller functional groupings \cite{maikowski}.
+\item It must be possible for multiple (simultaneous) failure modes to be modelled.% from the base component level up.
+\end{itemize}
+}
 
+% A new methodology must ensure that it represents all component failure modes and it therefore should be bottom-up, 
+% starting with individual component failure modes. 
+% 
+% In order to control the state explosion problem, the process must be modular
+% and deal with small groups of components. The design process follows this 
+% rationale, sub-systems are build to perform often basic functions from base components.
+% We can term these small groups {\fgs}.
+% 
+% Components should be collected
+% into small functional groups to enable the examination of the effect of a
+% component failure mode on the other components in the group.
+% Once we have the failure modes, or symptoms of failure of a {\fg}
+% it can now be considered as `derived component' with a known set 
+% of failure symptoms. We can use this `derived component' to build higher level 
+% functional groups.
+% 
+% This helps with the reasoning distance problem,
+% because we can trace failure modes back through complex interactions and have a structure to
+% base our reasoning on, at each stage.
+% 
 
 
 %Development of the new methodology 
 
 \section{An ontology of failure modes}
 
-An ontology is developed of 
+An ontology is now developed of  
 failure modes and their relationship to environmental factors, 
-operational states and the hierarchical nature inherent in product design, 
+applied/operational states and the hierarchical nature inherent in product design, 
 defining the relationships between the system as a whole, components, 
 failure modes, operational and environmental states. 
 
-DEVELOP UML MODELS
+
+Components have sets of failure modes associated with them.
+Failure modes for common components may be found in 
+the literature~\cite{fmd91},~\cite{mil1991}.
+We can associate a component with its failure modes.
+This is represented in UML in figure \ref{fig:component_concept}.
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=200pt,keepaspectratio=true]{./component.png}
+ % component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76
+ \caption{Component with failure modes UML diagram}
+ \label{fig:component_concept}
+\end{figure}
+
+
+\subsection{Modular Design}
+
+When designing a system from the bottom-up, small groups of components are selected to perform
+simple functions. These can be termed {\fgs}.
+When the failure mode behaviour, or symptoms of failure 
+of a {\fg} are determined, it can be treated as a component in its own right.
+
+% Functional groups
+% are then brought together to form more complex and higher level {\fgs}.
+Used in this way the {\fg} has become a {\dc}. The symptoms of failure
+of the {\fg} can be considered the failure modes of its {\dc}.
+Derived~Components can be used to create higher level {\fgs}.
+Repeating this process will lead to identify-able higher level
+groups, often referred to as sub-systems. We can call the entire collection/hierarchy
+of sub-systems the SYSTEM. 
+
+ 
+\subsection{Environmental Conditions, Operational States}
+
+Any real world sub-system will exist in a variable environment
+and may have several modes of operation.
+In order to find all possible failures, a sub-system 
+must be analysed for each operational state
+and environmental condition that could affect it.
+%
+A question is raised here: which objects should we 
+associate  the environmental and the operational states with ?
+There are three objects in our model to which these considerations could be applied.
+We could apply these conditions  
+to {\fgs}, components, or {\dcs}.
+
+\paragraph {Environmental Conditions.}
+
+Environmental conditions are external to the
+{\fg} and are often things over which the system has no direct control.
+Consider ambient temperature, pressure or even electrical interference levels.
+%
+Environmental conditions may affect different components in a {\fg}
+in different ways.
+
+For instance, a system may be specified for
+$0\oc$  to $85\oc$ operation, but some components
+may show failure behaviour between $60\oc$  and $85\oc$ 
+\footnote{Opto-isolators typically show marked performance decrease after
+$60\oc$ \cite{tlp181}, whereas another common component, say a resistor, will be unaffected.}.
+Other components may operate comfortably within that whole temperature range specified.
+Environmental conditions will have an effect on the {\fg} and the {\dc},
+but they will have specific effects on individual components.
+
+It seems obvious that
+environmental conditions should apply to components.
+%A component will hold a set of environmental states that
+%affect it. 
+
+\paragraph {Operational States}
+
+Sub-systems may have specific operational states.
+These could be a general health level, such as 
+normal operation, graceful degradation or lockout.
+Alternatively they could be self~checking sub-systems that are either in a normal, alarm/lockout or self~check state.
+
+Operational states are conditions that apply to some functional groups, not individual components.
+%% Andrew says that that does no make sense But I think it does
+%
+%\paragraph{Design Decision.}
+%Operational state  will be applied to {\fg}s.
+%
+%\paragraph{UML Model of FMMD Analysis}
+%
+The UML diagram in figure \ref{fig:env_op_uml}, shows the data
+relationships between {\fgs} and operational states, and component
+failure modes and environmental factors.
+
+
+% \begin{figure}[h]
+%  \centering
+%  \includegraphics[width=200pt,bb=0 0 818 249,keepaspectratio=true]{./fmmd_env_op_uml.png}
+%  % fmmd_env_op_uml.jpg: 818x249 pixel, 72dpi, 28.86x8.78 cm, bb=0 0 818 249
+%  \caption{UML model of Environmental and Operational states w.r.t FMMD}
+%  \label{fig:env_op_uml}
+% \end{figure}
+
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=200pt]{./fmmd_env_op_uml.png}
+ % fmmd_env_op_uml.png: 816x246 pixel, 72dpi, 28.79x8.68 cm, bb=0 0 816 246
+ \caption{UML model of failure mode ontology}
+ \label{fig:env_op_uml}
+\end{figure}
+
+%This is because environmental conditions will apply SYSTEM wide,
+%but may only affect specific components.
+
+%DEVELOP UML MODELS
 
 
 
-The ontology is used 
-to determine the nature of a hierarchy modelling the system, and to which 
-entities, various conditions/procedures are germane. From the ontology, 
-we determine that environmental effects relate to components, and 
-operational states to functional groups. A functional group can be 
-analysed with respect to its component failure modes, operational 
-states and environmental conditions and from this a set of failures 
-modes, or symptoms for the functional group can be determined. A functional group 
-can be treated as a derived component. Derived components can be 
-used to build functional groups at a higher level. In this manner we 
+\section{The proposed Methodology}
+\label{fmmdproc}
+The proposed methodology is a bottom-up process
+starting with base~components.
+These are collected into functional groups
+and each component failure mode (and optionally combinations) are considered in the 
+context of the {\fg}. These are termed `test~cases'. For each test~case
+there will be a corresponding failure mode, from the perspective of the {\fg}.
+A symptom collection stage will now be applied. Here common symptoms are collected
+from the results of the test~cases.
+With a collection of the {\fg} failure symptoms, we can now create a {\dc}.
+The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from.
+
+By using {\dcs} in higher level functional groups, a hierarchy can be built representing
+the failure mode behaviour of a SYSTEM.
+
+
+\subsection{Re-Factoring the UML Model}
+
+The UML models thus far % in this 
+have been used to develop the ontology. % data relationships required to perform FMMD analysis.
+We can now re-organise and rationalise the UML model.
+We want to be able to use {\dcs} in functional groups.
+It therefore makes sense for {\dc} to inherit {\em component}.
+
+
+
+
+% \begin{figure}[h]
+%  \centering
+%  \includegraphics[width=200pt,bb=0 0 702 464]{./master_uml.png}
+%  % master_uml.jpg: 702x464 pixel, 72dpi, 24.76x16.37 cm, bb=0 0 702 464
+%  \caption{Re-factored UML Diagram}
+%  \label{fig:refactored_uml}
+% \end{figure}
+
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=200pt]{./master_uml.png}
+ % master_uml.png: 700x462 pixel, 72dpi, 24.69x16.30 cm, bb=0 0 700 462
+ \caption{Re-factored UML Diagram }
+ \label{fig:refactored_uml}
+\end{figure}
+
+The re-factored UML diagram is shown in figure \ref{fig:refactored_uml}; with this structure
+{\dcs} can be 
+used to build {\fgs} at a higher level. In this manner we 
 can build a hierarchical model with each layer consisting of 
-components derived from the functional groups of derived components.
-From the ontology, a set of rules for simplifying the failure 
-modes (collecting them into common symptoms) as we traverse up the 
-hierarchy is developed. The hierarchical model can have layers added 
-until it converges to a top level single functional group. On collecting 
-symptoms from this, we are left with the top level, or system level, failure modes.
+components derived from the functional groups of derived components,
+until we arrive at a SYSTEM level.
+The symptoms of the {\fg} at the top represent the SYSTEM failure modes.
+
+
+%From the ontology, a set of rules for converting  the {\fgs}
+%(collecting common symptoms) to {\dcs} as we traverse up the 
+%hierarchy is developed. The hierarchical model can have layers added 
+%until it converges to a top level single functional group.
+
+%On collecting 
+%symptoms from this, we are left with the top level, or system level, failure modes.
+
+\paragraph{Diagramatic Notation based on Euler Diagrams}
+
 The model is presented in a diagrammatic notation that has been 
-designed to be intuitive and understandable. It uses well tested 
+designed to be intuitive and understandable.
+%
+It uses well tested 
 visual techniques to represent the elements of the model and their 
-relationships. Software support for the development of models in this 
+relationships. 
+%
+Software support for the development of models in this 
 notation has been designed and proof-of-concept tools have been implemented.
 
 
+\subsection{Justification of wishlist}
 
+By applying the methodology in section \ref{fmmdproc}, the wishlist can
+now be evaluated for the proposed FMMD methodology.
+
+{ \small
+\begin{itemize}
+\item{State Explosion must be reduced.}
+Because small collections of components are dealt with in functional groups
+the state explosion problem is effectively dealt with.
+
+\item{All component failure modes must be considered in the model.}
+The proposed methodology will be bottom-up. 
+This ensures that all component failure modes are handled.
+
+
+\item{ It should be easy to integrate mechanical, electronic and software models.}
+Because component failure modes are considered, we have a generic entity to model.
+We can describe a mechanical, electrical or software component in terms of its failure modes. 
+%
+Because of this 
+we can model and analyse integrated electromechanical systems, controlled by computers,
+using a common notation.
+
+\item{ It should be re-usable, in that commonly used modules can be re-used in other designs/projects.}
+The hierarchical nature, taking {\fg}s and deriving components from them, means that 
+commonly used {\dcs} can be re-used in a design (for instance self checking digital inputs)
+or even in other projects where the same {\dc} is used.
+
+
+
+\item{ It should have a formal basis, data should be available to produce mathematical proofs
+for its results}
+Because the failure mode of a SYSTEM is a hierarchy of {\fg}s and derived components
+SYSTEM level failure modes are traceable back down the fault tree to
+component level failure modes. This provides causation trees \cite{sccs} or, minimal cut sets
+for all SYSTEM failure modes.
+
+\item{ It should be capable of producing reliability and danger evaluation statistics.}
+The minimal cuts sets for the SYSTEM level failures can have computed MTTF
+and danger evaluation statistics sourced from the component failure mode statistics \cite {mil1991}.
+
+\item{ It should be easy to use, ideally 
+using a graphical syntax (as opposed to a formal mathematical one).}
+A modified form of constraint diagram (an extension of Euler diagrams) has
+been developed to support the FMMD methodology.
+This uses Euler circles to represent failure modes, and spiders to collect symptoms, to
+advance a {\fg} to a {\dc}.
+
+
+\item{ From the top down the failure mode model should follow a logical de-composition of the functionality
+to smaller and smaller functional modules \cite{maikowski}.}
+The bottom-up approach fulfils the  logical de-composition requirement, because the {\fg}s
+are built from components performing a given task. 
+
+
+\item{ Multiple failure modes may be modelled from the base component level up.}
+By breaking the problem of failure mode analysis into small stages
+and building a hierarchy, the problems associated with the cross products of
+all failure modes within a system are reduced by an exponential order.
+This is because the multiple failure modes are considered
+within {\fgs} which have fewer failure modes to consider 
+at each FMMD stage.
+Where appropriate, multiple simultaneous failures can be modelled by
+introducing test~cases where the conjunction of failure modes is considered.
+\end{itemize}
+}
+
+%\clearpage
 \section{Conclusion}
 
 This new approach is called 
@@ -291,7 +511,7 @@ particular field. It can be applied to mechanical, electrical or software domain
 It can therefore be used to analyse systems comprised of electrical,
 mechanical and software elements in one integrated model.
 
-
+\today
 %
 { \tiny
 \bibliographystyle{plain}
diff --git a/fmmd_concept/fmmd_concept.tex b/fmmd_concept/fmmd_concept.tex
index fc616af..ac427c3 100644
--- a/fmmd_concept/fmmd_concept.tex
+++ b/fmmd_concept/fmmd_concept.tex
@@ -684,7 +684,66 @@ to smaller and smaller functional groupings \cite{maikowski}.
 
 \section{Design of a new static failure mode based methodology}
 
-\paragraph{New methodology must be bottom-up.}
+
+%
+
+By taking {\dcs} to form higher level functional groups
+we can build a bottom-up model incrementally.
+In this way as we build the hierarchy, we naturally abstract the 
+failure mode behaviour, but can check that all failure modes in 
+the hierarchy have been considered and tied to causing symptoms.
+
+\paragraph{Design Decision: Derived components must be determined from functional groups.}
+The symptoms obtained from analysing a {\fg} will be used as the `failure~modes'
+of its corresponding {\dc}.
+
+\paragraph{Incremental Stages and \dcs .}
+We can use incremental stages to build the hierarchy.
+We can take small {\fg}s of components, where the {\fg}
+is a small set of components that perform a simple
+task.
+%
+%The functional group should perform a clearly defined task.
+The design engineer must choose the components that form a {\fg}.
+It should be possible to consider the {\fg} as a component or
+black box, performing a given function.
+The {\fg} should be chosen to be as small 
+(in terms of the number of components) as possible.
+%
+This should be small enough to be able %Another advantage of the functional group being small
+to comfortably analyse all the failure
+modes of its components.
+%
+We can consider these failure modes from the perspective
+of the {\fg}. In other words, for each component failure mode in the {\fg},
+we create a `test case' and decide how each failure affects the functional group.
+%
+With the results from the test cases we will now have the ways in which the 
+{\fg} can fail.
+%
+%
+We can refine this further, by grouping the common symptoms, or results that
+are the same failure {\wrt} the {\fg}.
+%
+We can now treat the {\fg} as a component, and create a corresponding {\dc}: in other words, a `sub-system' with a known set of failure modes.
+%
+We can now create a new/{\dc} and assign it these common symptoms
+as its failure modes.
+%
+This {\dc} can be used to build higher level
+{\fg}s, and this will naturally form a hierarchy.
+This hierarchy can be extended until it encompasses 
+an entire SYSTEM. 
+%
+It can be considered complete when
+all failure modes from all components are included in the model
+and all base component failure modes can be traced
+through the fault tree to SYSTEM level failure modes.
+
+\paragraph{Directed Acyclic Graph (DAG).} 
+If we ensure that
+derived components cannot be included in {\fg}s
+of a lower abstraction level\paragraph{New methodology must be bottom-up.}
 In order to ensure that all component failure modes have been covered
 the methodology will have to work from the bottom-up
 and start with the component failure modes.
@@ -826,65 +885,6 @@ When we have the symptoms, we can start thinking of the {\fg} as a component in
 %
 We can now create a new {\dc}, where its failure modes
 are the failure symptoms of the {\fg}.
-%
-
-By taking {\dcs} to form higher level functional groups
-we can build a bottom-up model incrementally.
-In this way as we build the hierarchy, we naturally abstract the 
-failure mode behaviour, but can check that all failure modes in 
-the hierarchy have been considered and tied to causing symptoms.
-
-\paragraph{Design Decision: Derived components must be determined from functional groups.}
-The symptoms obtained from analysing a {\fg} will be used as the `failure~modes'
-of its corresponding {\dc}.
-
-\paragraph{Incremental Stages and \dcs .}
-We can use incremental stages to build the hierarchy.
-We can take small {\fg}s of components, where the {\fg}
-is a small set of components that perform a simple
-task.
-%
-%The functional group should perform a clearly defined task.
-The design engineer must choose the components that form a {\fg}.
-It should be possible to consider the {\fg} as a component or
-black box, performing a given function.
-The {\fg} should be chosen to be as small 
-(in terms of the number of components) as possible.
-%
-This should be small enough to be able %Another advantage of the functional group being small
-to comfortably analyse all the failure
-modes of its components.
-%
-We can consider these failure modes from the perspective
-of the {\fg}. In other words, for each component failure mode in the {\fg},
-we create a `test case' and decide how each failure affects the functional group.
-%
-With the results from the test cases we will now have the ways in which the 
-{\fg} can fail.
-%
-%
-We can refine this further, by grouping the common symptoms, or results that
-are the same failure {\wrt} the {\fg}.
-%
-We can now treat the {\fg} as a component, and create a corresponding {\dc}: in other words, a `sub-system' with a known set of failure modes.
-%
-We can now create a new/{\dc} and assign it these common symptoms
-as its failure modes.
-%
-This {\dc} can be used to build higher level
-{\fg}s, and this will naturally form a hierarchy.
-This hierarchy can be extended until it encompasses 
-an entire SYSTEM. 
-%
-It can be considered complete when
-all failure modes from all components are included in the model
-and all base component failure modes can be traced
-through the fault tree to SYSTEM level failure modes.
-
-\paragraph{Directed Acyclic Graph (DAG).} 
-If we ensure that
-derived components cannot be included in {\fg}s
-of a lower abstraction level
 the data structure produced from collecting functional groups
 and deriving components will naturally form a DAG.
 In other words we can say that we cannot allow a {\fg}