.:wq

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -129,7 +129,7 @@ determine the likelihood of component failures
 causing specific system level errors. For example, Bayes theorem \ref{bayes}, the relation between a conditional probability and its inverse,
 can be applied to specific failure modes in components and the probability of them causing given system level errors.
 Another top down technique is to apply cost benefit analysis 
-to determine which faults are the highest priority to fix\cite{FMEA}.
+to determine which faults are the highest priority to fix\cite{bfmea}.
 The aim of FMMD analysis is to produce complete  failure
 models of safety critical systems  from the bottom-up,
 starting, where possible with known base~component failure~modes.

fmmdset/fmmdset.tex

@@ -7,8 +7,8 @@
 \begin{abstract} 
 This paper describes a process for analysing safety critical systems, to formally prove how safe the
 designs and built -in safety measures are. It provides
-the rigourous method for creating a fault effects model of a system from the bottom up  using base~component level fault modes.
-Using symptom extraction, and taking functional~groups of components, a fault behaviour
+the rigourous method for creating a fault effects model of a system from the bottom up  using {\bc} level fault modes.
+Using symptom extraction, and taking {\fgs} of components, a fault behaviour
 hierarchy is built, forming a fault model tree.
 From the fault model trees, 
 modular re-usable sections of safety critical systems,
@@ -89,28 +89,27 @@ The main idea of the methodology is to build a hierarchy of fault modes from the
 level up to highest system levels. 
 
 The first stage is to choose
-components that interact and naturally form {\em functional groups}. {Functional groups} are thus collections of base parts.
+components that interact and naturally form {\fgs}. The initial {\fgs} are thus collections of base parts.
 %These parts all have associated fault modes. A module is a set fault~modes. 
-
 From the point of view of fault analysis, we are not interested in the components themselves, but in the ways in which they can fail.
 
-For this study a functional group will mean a collection of components.
-In order to determine the symptoms or failure modes of a {\em functional group}
+For this study a {\fg} will mean a collection of components.
+In order to determine the symptoms or failure modes of a {\fg}
 we need to consider all failure modes of its components.
 By analysing the fault behaviour of a `functional group' with respect these failure modes
 we can derive a new set of possible failure modes.
 %
-This new set of faults is the set of derived faults from the perspective of the functional~group, and is thus at a higher level of 
-fault~mode abstraction. Thus we can say that the functional~group as an entity, can fail in a number of well defined ways.
+This new set of faults is the set of derived faults from the perspective of the {\fg}, and is thus at a higher level of 
+fault~mode abstraction. Thus we can say that the {\fg} as an entity, can fail in a number of well defined ways.
 
-In other words we have taken a functional group, and analysed how it can fail according to the failure modes of its parts.
+In other words we have taken a {\fg}, and analysed how it can fail according to the failure modes of its parts.
 These new failure~modes are derived failure modes.
 %The ways in which the module can fail now becomes a new set of fault modes, the fault~modes
 %being derived from the functional~group. 
-We can now create a new `derived~component' which has
+We can now create a new `{\dc}' which has
 the failure symptoms of the functional~group as its set of failure modes.
 This new derived~component is at a higher failure mode abstraction
-level than the base components.
+level than the {\bcs}.
 %What this means is the `fault~symptoms' of the module have been derived.
 %
 %When we have determined the fault~modes at the module level these can become a set of derived faults.
@@ -119,19 +118,25 @@ level than the base components.
 %to represent the fault behaviour of the entire system. This can be seen as using the modules we have analysed
 %as parts, parts which may now be combined to create new functional groups, 
 %but as parts at a higher level of fault abstraction. 
-Applying the same process with derived components we can bring derived components
-together to form functional groups and create new derived components
+Applying the same process with {\dcs} we can bring {\dcs}
+together to form functional groups and create new {\dcs}
 at a higher abstraction level.
+\ifthenelse {\boolean{paper}}
+{
+Reference the symptom abstraction paper here
+}
+{
+This analysis and symptom collection process is described in detail in the Symptom extraction chapter\ref{symptomex}.
+}
 
-This analysis and symptom collection process is described in detail in the Symptom extraction chapter.
 
 \subsubsection { Definitions }
 
 \begin{itemize}
-\item base component - a component with a known set of unitary state failure modes 
-\item functional group -  a collection of components chosen to perform a particular task
-\item derived failure mode - a failure symptom of a functional group
-\item derived component - a functional group after analysis
+\item {\bc} - a component with a known set of unitary state failure modes 
+\item {\fg} -  a collection of components chosen to perform a particular task
+\item {\em derived failure mode} - a failure symptom of a functional group
+\item {\dc} - a new component derived from an analysed {\fg}
 \end{itemize}
 
 \subsubsection{An algebraic notation for identifying FMMD enitities}
@@ -163,29 +168,29 @@ the abstraction level zero thus $C^0$. Should we wish to index the components
 Our base component (if first in the parts~list) could now be uniquely identified as
 $C^0_1$.
 
-A functional group can use the variable name $FG$. A functional group is a collection
+A {\fg} can use the variable name $FG$. A {\fg} is a collection
 of components. We thus define $FG$ as a set of components that have been chosen as members 
-of a functional~group.
-We can further define the abstraction level of a functional group.
+of a {\fg}.
+We can further define the abstraction level of a {\fg}.
 We can say that it is the maximum abstraction level of any of its
 components. Thus a functional group containing only base components
 would have an abstraction level zero and could be represented with a superscript of zero thus
 $FG^0$. The functional group set may also be indexed.
 
-We can apply symptom abstraction to a functional group to find
+We can apply symptom abstraction to a {\fg} to find
 a set of derived failure modes. We are interested in the failure modes
-of all the components in the functional group. An analysis process
-defined by the symbol  `$\bowtie$' is applied to the functional~group.
+of all the components in the {\fg}. An analysis process
+defined by the symbol  `$\bowtie$' is applied to the {\fg}.
 Using $\alpha$ to symbolise the fault abstraction level, we can state:
 
 $$ \bowtie(FG^{\alpha}) \rightarrow C^{{\alpha}+1} $$ 
 
 The $\bowtie$ function processes each member (component) of the set $FG$ and 
 extracts all the component failure modes, which are used by the analyst to
-determine the derived failure modes. A new derived component is created
+determine the derived failure modes. A new {\dc} is created
 where its failure modes are the symptoms from $FG$.
-Note that the component will have a higher abstraction level than the functional
-group it analysed.
+Note that the component will have a higher abstraction level than the {\fg}
+it was derived from.
 
 \subsubsection{FMMD Hierarchy}
 
@@ -196,10 +201,10 @@ An example of a simple system will illustrate this.
 
 \subsection {Example FMEA process using an FMEA diagram}
 
-Consider a simple functional~group  $ FG^0_1 $ derived from two base components $C^0_1,C^0_2$.
+Consider a simple {\fg}  $ FG^0_1 $ derived from two base components $C^0_1,C^0_2$.
 
-We can apply $\bowtie$ to the functional~group $FG$ 
-and it will return a derived component at abstraction level 1 (with an index of 1 for completeness)
+We can apply $\bowtie$ to the {\fg} $FG$ 
+and it will return a {\dc} at abstraction level 1 (with an index of 1 for completeness)
 
 $$ \bowtie( FG^0_1 ) = C^1_1 $$
 
@@ -212,10 +217,10 @@ By way of exqample applying ${FM}$ to obtain the failure modes $f_N$
  $$ {FM}(C^0_2) = \{ f_3, f_4, f_5 \}  $$  
 
 
-The analyst now considers failure modes $f_{1..5}$ in the context of the functional group.
+The analyst now considers failure modes $f_{1..5}$ in the context of the {\fg}.
 The result of this process will be a set of derived failure modes.
 Let these be $  \{ s_6, s_7, s_8 \} $.
-We can now create a derived component $C^1_1$ with this set of failure modes.
+We can now create a {\dc} $C^1_1$ with this set of failure modes.
 
 Thus:
 
@@ -257,15 +262,15 @@ We can represent this analysis process in a diagram see figure \ref{fig:onestage
 Figure \ref{fig:fmmdh} shows a hierarchy of failure mode de-composition.
 
 It can be seen that the derived fault~mode sets are higher level abstractions of the fault behaviour of the modules.
-We can take this one stage further by combining the derived component $C^{1}_{{N}}$ sets to form functional~groups. These 
-$FG^2_{N}$ functional~groups can be used to create $C^3_{{N}}$ derived components and so on.
+We can take this one stage further by combining the {\dc} $C^{1}_{{N}}$ sets to form {\fgs}. These 
+$FG^2_{N}$ {\fgs} can be used to create $C^3_{{N}}$ {\dcs} and so on.
 At the top of the hierarchy, there will be one final (where $t$ is the 
 top level) component $C^{t}_{{N}}$ and {\em its fault modes, are the failure modes of the SYSTEM}. The causes for these
 system level fault~modes will be traceable down to part fault modes, traversing the tree
-through the lower level functional groups and components. 
+through the lower level {\fgs} and components. 
 each SYSTEM level fault may have a number of paths through the 
 tree to different low level of base component failure modes.
-In FTA terminology, these paths through the tree are called `minimal cut sets'.
+In FTA\cite{nucfta}\cite{nasafta}  terminology, these paths through the tree are called `minimal cut sets'.
 
 
 A hierarchy of levels of faults becoming more abstract at each level should
@@ -276,7 +281,7 @@ real time control systems often have a small number of major reportable faults (
 even though they may have accompanying diagnostic data.
 
 
-The FMMD hierarchy is of the form of a directed acyclic graph. 
+The FMMD hierarchy is of the form of a directed acyclic graph\cite{alg}. % XXX better citation really required
 Each stage of analysis builds the acyclic graph by adding to the top of the tree, leaving the previous work
 unchanged, very much in the way that the source code control system git\cite{git}
 manages source code trees.
@@ -346,11 +351,11 @@ with any error messages.
 
 % in CRC checksum protected packets.
 
-It is interesting to look at one of `functional~groups'. The milli-volt amplifiers are a good example.
-These can be analysed by taking a functional~group, the components surrounding the op-amp, 
+It is interesting to look at a particular {\fg}. The milli-volt amplifiers are a good example.
+These can be analysed by taking a {\fg}, the components surrounding the op-amp, 
 a few resistors to determine offset and gain,
 a safety resistor, and perhaps some smoothing capacitors.
-These components form a functional group. This circuit is then analysed for all the fault combinations 
+These components form a {\fg}. This circuit is then analysed for all the fault combinations 
 of its parts. This produces a collection of possible symptoms/fault~modes for the milli-volt amplifier.
 The two amplifiers are now connected to an ADC which converts the voltages to binary words for the microprocessor.
 The micro-processor then uses the values to determine if the readings are valid and then formats text to send
@@ -383,7 +388,7 @@ via the RS232 serial line.
 %  \label{fig:mvs}
 % \end{figure}
 
-This has a number of obvious functional~groups, the PCB power supply, the milli-volt amplifiers,
+This has a number of obvious {\fgs}, the PCB power supply, the milli-volt amplifiers,
 the analog to digital conversion circuitry, the micro processor and the UART (serial link - RS232 transceiver).
 It would make sense when analysing this system to take each one of these functional~groups in turn and examine them closely.
 

fzd/fzd.tex

@@ -676,7 +676,7 @@ Note : In figure \ref{fig:picwaie} note that contours \em{D} and \em{E} are in
 \subsection { Rule 5: Multiple Zone Creation }
 
 
-A circular reference (often described as a circuit \cite{gtl} \cite{alggraph}) containing more than one pair of pure intersections
+A circular reference (often described as a circuit\cite{alg}) containing more than one pair of pure intersections
  indicates the possibility
 of a multiple  intersection of the contours in the path. The converse is true. 
 Should there be no circular path, there can be 

introduction/introduction.tex

@@ -297,9 +297,9 @@ A classic example of an automated system failing, is the therac-25.
 This was an X-ray dosage machine, that, due to software errors
 caused the deaths of several patients and injured more during the 1980's.
 The Therac-25 was a designed from a manual system, which had checks and interlocks,
-and was subsequently computerised. Software bugs were the primary causes of the radiation
+and was subsequently computerised. Software safety interlock problems were the primary causes of the radiation
 overdoses.  
-\cite{therac}
+\cite{safeware}[App. A]
 Any new safety critical analysis methodology should
 be able to model software, electrical and hardware faults using 
 a common notation.
@@ -484,13 +484,16 @@ On the day of the launch the temperature of this seal was out of range.
 A bottom up safety approach would have revealed this as a fault.
 
 The FTA in use by NASA and the US Nuclear regulatory commisssion 
-allows for enviromental considerations such as temperature\cite{NASA}\cite{NUK}.
+allows for enviromental considerations such as temperature\cite{nasafta}\cite{nucfta}.
 But because of the top down nature of the FTA technique, the safety designer must be aware of
 the environemtnal constraints of all component parts in order to use this correctly.
 This element of FTA is discussed in \ref{surveysc}
 
 \section{Therac 25}
 
+
+\cite{safeware}[App. A]
+
 %% Here need more detail of what therac 25 was and roughly how it failed
 %% with refs to nancy
 %% and then highlight the fact that the safety analysis did not integrate software and hardware domains.

mybib.bib

@@ -36,7 +36,19 @@
   YEAR =         "2009"
 }
 
+@BOOK{ince,
+  AUTHOR =       "D. C. Ince",
+  TITLE =        "In Introduction to discrete Mathematics, Formal System specification and Z",
+  PUBLISHER =      "Oxford University Press",
+  YEAR =         "1992"
+}
 
+@BOOK{safeware,
+  AUTHOR =       "Nancy Leveson",
+  TITLE =        "Safeware: System safety and Computers ISBN:  0-201-11972-2",
+  PUBLISHER =      "Addison-Wesley",
+  YEAR =         "2005"
+}
 
 @BOOK{bfmea,
   AUTHOR =       "Robin E McDermot et all",

statistics/statistics.tex

@@ -82,7 +82,7 @@ probablistic approach - no direct causation paths to the higher~abstraction faul
 Often for instance a component in a module within a module within a module etc
 that has a probability of causing a SYSTEM level fault.
 
-Philosophy behind  FTA\cite{NASA}\cite{NUK}.
+Philosophy behind  FTA\cite{nasafta}\cite{nucfta}.
 The idea being that probabilities can be assigned to components 
 failing, causing system level errors.
 

style.tex

@@ -68,6 +68,12 @@
 \newcommand{\adctw}{{${\mathcal{ADC}}_{12}$}}
 \newcommand{\adcten}{{${\mathcal{ADC}}_{10}$}}
 \newcommand{\ohms}[1]{\ensuremath{#1\Omega}}
+\newcommand{\fg}{\em functional~group}
+\newcommand{\fgs}{\em functional~groups}
+\newcommand{\dc}{\em derived~component}
+\newcommand{\dcs}{\em derived~components}
+\newcommand{\bc}{\em base~component}
+\newcommand{\bcs}{\em base~components}
 %----- Display example text (#1) in typewriter font
  
 %\newcommand{\example}[1]{\\ \smallskip\hspace{1in}{\tt #1}\hfil\\

symptom_ex_process/symptom_ex_process.tex

@@ -11,6 +11,7 @@
 
 }
 {
+\label{symptomex}
 \input{./symptom_ex_process/introduction}
 \input{./symptom_ex_process/topbot}
 %\input{./symptom_ex_process/sys_abs}

vmgbibliography.bib

@@ -98,6 +98,16 @@
 }
 
 
+@ARTICLE{howse:spider,
+  AUTHOR =       "John Howse, Gem Stapleton and John Taylor",
+  TITLE =        "Spider Diagrams",
+  JOURNAL =      "London Mathematical Society",
+  volume =       "8",
+%  number =       "4",
+  pages =        "145-194",
+  month =        "December",
+  YEAR =         "2005"
+}
 
 @conference{akehurst:o2.0its,
     author      = "D.~Akehurst and P.~Linington and O.~Patrascoiu",