Morning edit

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -80,7 +80,7 @@ The UML diagram in figure
 structure with its associated failure modes.
 
 From this diagram we see that each component must have at least one failure mode.
-To clearly show that the failure modes are unique events associated with one component,
+To clearly show that the failure modes are mutually exclusive states, or unitary states associated with one component,
 each failure mode is referenced back to only one component. 
 
 %%-%% MTTF STATS CHAPTER MAYBE ??
@@ -95,11 +95,11 @@ each failure mode is referenced back to only one component.
 A product naturally consists of many components and these are traditionally
 kept in a `parts list'. For a safety critical product this is usually a formal document
 and is used by quality inspectors to ensure the correct parts are being fitted.
-For our UML diagram the parts list is simply a collection of components 
-as shown in figure \ref{fig:componentpl}. The parts list is shown for
+The parts list is shown for
 completeness here, as people involved with PCB and electronics production, verification
 and testing would want to know where it lies in the model.
 The parts list is not actively used in the FMMD method.
+For the UML diagram in figure \ref{fig:componentpl} the parts list is simply a collection of components.
 \begin{figure}[h]
  \centering
  \includegraphics[width=400pt,bb=0 0 712 68,keepaspectratio=true]{component_failure_modes_definition/componentpl.jpg}
@@ -108,14 +108,18 @@ The parts list is not actively used in the FMMD method.
  \label{fig:componentpl}
 \end{figure}
 
-Components in the parts list (bought in parts) will be termed `base~components'.
-Components derived from base~components may not require 
+Components in the parts list % (bought in parts) 
+will be termed `base~components'.
+Components derived from base~components will not always require 
 parts~numbers\footnote{It is common practise for sub assemblies, PCB's, mechanical parts,
-software modules and some collections of components to have part numbers.}, and will
-not require a vendor reference, but must be named.
+software modules and some collections of components to have part numbers.
+This is a production/configuration~control issue and linked to Bill of Material (BOM)
+database structures etc. Parts numbers for derived components are not directly related to the analysis process
+we are concerned with here.}, and will
+not require a vendor reference, but must be named locally in the FMMD model.
 
 We can term `modularising a system', to mean recursively breaking it into smaller sections for analysis.
-When modularising a system from the top~down, as in Fault Tree Analysis (FTA)
+When modularising a system from the top~down, as in Fault Tree Analysis\cite{nasafta}\cite{nucfta} (FTA)
 it is common to term the modules identified as sub-systems.
 When building from the bottom up, it is more meaningful to call them `derived~components'.
  
@@ -140,36 +144,44 @@ starting, where possible with known base~component failure~modes.
 
 An advantage of working from the bottom up is that we can ensure that
 all component failure modes must be considered. A top down approach
-could miss individual failure modes of components.
+can miss individual failure modes of components\cite{faa}[Ch.~9],
+especially where they are non obvious top-level faults.
 
 In order to analyse from the bottom-up, we need to take
 small groups of components from the parts~list that naturally
-work together to perform a simple function.
-The components to include in a  functional group are chosen by a human, the analyst.
+work together to perform a simple function;
+the components to include in a  {\fg} are chosen by a human, the analyst.
 %We can represent the `Functional~Group' as a class. 
  When we have a 
-`Functional~Group' we can look at the components it contains,
+`{\fg}' we can look at the components it contains,
 and from this determine the failure modes of all the components that belong to it.
 %
 % and determine a failure mode model for that group.
-The `Functional~Group' as used by the analyst is a collection of component failures modes.
+The `{\fg}' as used by the analyst is a collection of component failures modes.
 Each of these failure modes, and optionally combinations of them, are
-analysed for their effect on the failure mode behaviour of the `Functional~Group'.
+analysed for their effect on the failure mode behaviour of the `{\fg}'.
 %
 From this we can determine a new set of failure modes, the failure modes of the
-`Functional~Group'.
+`{\fg}'.
 % 
-Or in other words we can determine how the `Functional~Group' can fail.
-We can now consider the functional group as a sort of super component
+Or in other words we can determine how the `{\fg}' can fail.
+We can now consider the {\fg} as a sort of super component
 with a known set of failure modes.
 
 
 \subsection{From functional group to newly derived component}
 
-The process for taking a functional~group, considering
+The process for taking a {\fg}, considering
 all the failure modes of all the components in the group,
 and analysing it is called `symptom abstraction' and 
 is dealt with in detail in chapter \ref{symptom_abstraction}.
+% define difference between a \fg and a \dc
+A {\fg} is a collection of components, a {\dc} is a new `theorectical'
+component which has a set of failure modes, which
+correspond to the failure modes of the {\fg} is was derived from.
+We could consider a {\fg} as a black box, or component 
+to use, and in this case it would have a set of failure modes.
+Looking at the {\fg} in this way is seeing it as a {\dc}.
 
 In terms of our UML model, the symptom abstraction process takes a {\fg}
 and creates a new {\dc} from it.
@@ -192,7 +204,8 @@ We can represent this using a UML diagram in figure \ref{fig:cfg}.
 The symbol $\bowtie$ is used to indicate the analysis process that takes a
 functional group and converts it into a new component.
 
-\[ \bowtie ( FG ) \mapsto DerivedComponent \] 
+This can be expresed as
+\[ \bowtie ( FG ) \mapsto DerivedComponent \].
 
 
 \begin{figure}[h]

mybib.bib

@@ -65,6 +65,14 @@
 }
 
 
+@BOOK{faa,
+  AUTHOR =       "Federal Aviation Administration",
+  TITLE =        "System Safety Handbook",
+  PUBLISHER =    "http://www.faa.gov/library/manuals/aviation/risk\_management/ss\_handbook/",
+  YEAR =         "2008"
+}
+
+
 @BOOK{sccs,
   AUTHOR =       "Neil~Storey",
   TITLE =        "Safety-Critical Computer Systems ISBN 0-201-42787-7",