Evening edit...

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -338,7 +338,7 @@ fm : \mathcal{FG} \rightarrow \mathcal{F}
 
 
 \section{Unitary State Component Failure Mode sets}
-
+\label{sec:unitarystate}
 \paragraph{Design Descision/Constraint}
 An important factor in defining a set of failure modes is that they
 should represent the failure modes as simply and minimally as possible.

fmmd_concept/fmmd_concept.tex

@@ -1215,7 +1215,7 @@ for a single base~component failure mode minimal cut set~\cite{nucfta}.
 
 
 \subsection{Aims of FMMD Methodology}
-
+\label{sec:aims}
 Taking the four current failure mode methodologies into consideration, and comparing them to the proposed FMMD methodology, the following wish list or aims can be stated.
 
 \begin{itemize}

symptom_ex_process/algorithm.tex

@@ -6,8 +6,8 @@
 The algorithm for {\em symptom extraction} is described in 
 this section
 %describes the symptom abstraction process 
-using set theory.  
-
+using set theory and procedural descriptions.  
+%
 The {\em symptom abstraction process} (given the symbol `$\bowtie$') takes a functional group $FG$
 and converts it to a derived~component/sub-system $DC$.
 %The sub-system $SS$ is a collection
@@ -15,7 +15,8 @@ and converts it to a derived~component/sub-system $DC$.
 Note that
 $DC$ is a derived component at a higher level of fault analysis abstraction
 than the functional~group from which it was derived.
-Thus, it can be treated  
+%Thus, 
+$DC$ can be treated  
 as a component with a known set of failure modes.
 
 
@@ -55,7 +56,7 @@ naturally formed with the abstraction levels increasing with each tier.
 
 The algorithm, represented by the symbol `$\bowtie$', has been broken down into five consecutive stages.
 %These are described using the Algorithm environment in the next section \ref{algorithms}.
-By defining the process and describing it using set theory, constraints and 
+By defining the process and describing it using set theory. Constraints and 
 verification checks in the process are stated formally.
 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
@@ -82,7 +83,7 @@ $$ \bowtie: \mathcal{FG} \rightarrow \mathcal{DC} $$
 \end{algorithmic}
 \end{algorithm}
 
-The symptom abstraction methodology allows us to take a functional group of components,
+The symptom abstraction process allows us to take a functional group of components,
 analyse the failure
 mode behaviour and create a new entity, a derived~component, that has its own set of failure modes.
 The checks and constraints applied in the algorithm ensure that all component failure
@@ -179,7 +180,7 @@ given by
 
 $$ dtc(F) = TC $$
 
-The function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
+In algorithm \ref{alg2}, the function \textbf{chosen} means that the failure modes for a particular test case have been chosen by
 a human operator and are additional to those chosen by the automated process (i.e they are special case test cases involving multiple failure modes)
 The function \textbf{unitarystate} means that all test cases can have no pairs of failure modes sourced from the component.
 \ifthenelse {\boolean{paper}}
@@ -187,7 +188,7 @@ The function \textbf{unitarystate} means that all test cases can have no pairs o
 %% perhaps ref a paper here XXXXX
 }
 {
-This is discussed in section \ref{unitarystate}.
+This is discussed in section \ref{sec:unitarystate}.
 }
 %%
 %% Algorithm 2
@@ -337,9 +338,11 @@ The analysis is primarily a human activity.
 Each test case is examined in detail.
 %
 %
-Ideally calculations or simulations
+Calculations or simulations
 are performed to determine how the failure modes in each test case will
 affect the functional~group.
+Ideally field and formal physical testing data should be used in addition 
+where possible.
 %
 When the all the test cases have been analysed
 we will have a `result' for each `test case'.

symptom_ex_process/process.tex

@@ -3,14 +3,14 @@
 
 % TO DO: separate these two:
 
-\paragraph{Symptom Extraction Objective}
+\paragraph{Symptom Extraction Objective.}
 The objective of `symptom abstraction' is to analyse the functional~group and find 
 how it can fail
 when specified components within it fail.
 Once we know how a functional~group can fail, we can treat it as a component or sub-system
 with its own set of failure modes.
 
-\paragraph{FMEA applied to the Functional Group}
+\paragraph{FMEA applied to the Functional Group.}
 As the functional~group contains a set of components, the failure~modes
 that we have to consider are all the failure modes of its components, as
 developed in the function definition $fm : \;\mathcal{FG} \rightarrow \mathcal{F}$.
@@ -27,7 +27,7 @@ the test case conditions, for each test case.
 The goal of the process is to produce a set of failure modes from the perspective of the functional~group.
 %
 
-\paragraph{Environmental Conditions or Applied States}
+\paragraph{Environmental Conditions or Applied States.}
 
 Each test case must be considered  for all applied/operational states and 
 %in the for the case of each  applied states or
@@ -52,7 +52,7 @@ examine environmentally sourced common mode failure scenarios.
 %%- change due to enviromental factors.
 %%- 
 
-\paragraph{Symptom Identification}
+\paragraph{Symptom Identification.}
 When all `test~cases' have been analysed, a second phase can be actioned. % applied.
 %
 This looks at the results of the `test~cases' as failure modes from the perspective not of the components, but of the {\fg}/sub-system. 
@@ -66,7 +66,7 @@ will both cause the same failure; $no\_sound$ !
 
 
 
-\paragraph{Collection of Symptoms}
+\paragraph{Collection of Symptoms.}
 Looking at the functional group perspective failure modes, we can collect 
 some of these into common `symptoms'. Some test cases may cause
 unique failure modes at the functional group level. These can be termed
@@ -104,7 +104,7 @@ form `test cases'.
 % \item Where si,ultaneous failures are examined use overlapping contours
 % \item For each region on the diagram, make a test case
  \item Using the `test cases' as scenarios to examine the effects of component failures
-we determine failure~mode behaviour of the functional group. 
+we determine the failure~mode behaviour of the functional group. 
 This is a human process involving detailed analysis of the failure modes in the test case on the operation of the {\fg}.
 Where spcific environment conditions, or applied states are germane to the {\fg}, these must be examined
 for each test case.
@@ -260,8 +260,8 @@ We can thus apply the function $fm$ on this newly derived component thus:
 $$ fm(DC) = \{ SP1, SP2, SP3 \} $$
 
 Note that $g_6$ has \textbf{not disappeared from the analysis process}.
-Were the designer to have overlooked this test case, it would appear as a failure mode of the derived component.
-i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ would have been $ \{ SP1, SP2, g_6 \}$.
+Were the designer to have overlooked this test case, it could appear as a failure mode of the derived component.
+i.e. were it not to have been grouped in $SP3$, $ fm(DC)$ could have been $ \{ SP1, SP2, g_6 \}$.
 Because the process can be computerised, we can easily flag symptoms that have not been 
 included as failure modes in a {\dc}.
 % Aw boring ! no jokes ?
@@ -275,7 +275,7 @@ from base level components cannot be overlooked.
 {
 An advantage of a bottom-up process is that failure modes
 from base level components cannot be overlooked.
-The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{requirements}).
+The process must not allow failure modes to be ignored or forgotten (see project aims in section \ref{sec:aims}).
 }
 %
 This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component 

symptom_ex_process/topbot.tex

@@ -20,8 +20,8 @@ However, FMMD  also provides the mathematical framework
 to assist in the production of the three traditional methods of static analysis.
 From the model created by the FMMD methodology, statistical, FTA and FMEA models
 can be derived.
-FMMD can model electrical, mechanical and software using a common notation,
-and can thus model an entire electro-mechanical software controlled system.
+FMMD can model electrical, mechanical and software failures using a common notation,
+and can thus model an integrated electro-mechanical software controlled system.
 
 \subsection{Top Down or Natural Trouble Shooting}
 It is interesting here to look at the `natural' trouble shooting process.
@@ -95,7 +95,7 @@ that could cause a particular mode of equipment failure.
 This means that at the design stage of a product all component failure
 modes must be considered. The aim here is for complete failure mode coverage.
 This also means that we can obtain statistical estimates based on the known reliabilities
-of the components.
+of components\cite{mil1992}.
 %It also means that every component failure mode must at the very least be considered.
 
 
@@ -125,7 +125,7 @@ CD-player, tuner, amplifier~separate, loudspeakers and ipod~interface.
 %Thinking like this is a top~down analysis approach
 %and is the way in which FTA\cite{nucfta} analyses a System
 %and breaks it down.
-\paragraph{Sub-systems, {\fgs} and components}
+\paragraph{Sub-systems, {\fgs} and components.}
 A sub-system will be composed of components, which
 may themselves be sub-systems. However each `component'
 will have a fault/failure behaviour and it should
@@ -135,8 +135,7 @@ for each `component'.
 
 If we look at the sound system example, 
 the CD~player could fail in several distinct ways, 
-and this could be due to a large number of
-component failure modes.
+and this could  have been caused by a number of component failure modes.
 %no matter what has happened to it or has gone wrong inside it.
 
 
@@ -152,7 +151,7 @@ These are termed `functional~groups'. For instance the  circuitry that powers th
 to illuminate the CD might contain a handful of components, and as such would make a good candidate
 to be one of the base level functional~groups.
 
-\paragraph{Functional group to {\dc} process outline}
+\paragraph{Functional group to {\dc} process outline.}
 In choosing the lowest level (base component) sub-systems we would look 
 for the smallest `functional~groups' of components within a system. 
 We can define a functional~group as a set of components that interact
@@ -162,7 +161,7 @@ When we have analysed the fault behaviour of a functional group, we can treat it
 The fault behaviour will consist of a set of `symptoms' caused by combinations
 of its component failure modes.
 We can thus make a new `component' derived from the functional~group.
-The symptoms are the failure modes of this new `derived component'.
+The symptoms of the {\fg} are the failure modes of this new `derived component'.
 
 %We can now call our functional~group a sub-system or a derived~component. 
 %The goal here is to know how it will behave under fault conditions !