Big edit session

fmmd_concept/fmmd_concept.tex

@@ -133,6 +133,66 @@ are held in a computer program, we can determine if the model is complete
 %OK need to describe the need for it
 \section{The need for a new failure mode modelling methodology}
 
+%%- There are dificulties with bot up methodologies,
+%%- and this is in part due to the fact that accidents 
+%%- are always unforseen and unexpected.
+
+%%- what do we have ENV factors, component failure modes.
+
+%%- how difficult is it to take a single component failure mode and
+%%- then from that determine how it will react with other components
+%%- and how it will be affected 
+
+\subsection{General Comments on bottom-up and top down approaches}
+
+\paragraph{A general Problem with top-down}
+With a top down approach the investigator has to determine
+a set of undesireable outcomes or accidents.
+As most accidents are unexpected and the causes unforseen \cite{safeware} 
+it is fair to say that a top down approach is not guaranteed to
+predict all possible undesirable outcomes.
+It also can miss known component failure modes, by
+simple not de-composing down to that level of detail.
+
+\paragraph{A general problem with bottom-up}
+With the bottom up techniques we have all the known component failure modes
+and the freedom to determine how each of these may affect the SYSTEM.
+We do have a real prolem though in determining how
+the failure mode of one compoent will affect another working component
+to cause an undesirable state. Because of the number of components
+our one failure mode may interact with is large, 
+we cannot consider them all and human judgement is used to 
+decide which interactions are important.
+
+Let N be the number of components in our system, and K be the average number of component failure modes
+(ways in which the component can fail). The total number of base component failure modes
+is $N \times K$. To even examine the affect that one failure mode has on all the other components
+will be $$(N-1) \times N \times K$$, in effect a set cross product.
+
+
+Complicate this further with applied states or environmental conditions
+and another order of cross product of complexity is added.
+We may have a peice of self checking circuity for instance that
+has two states, normal and testing mode commanded by a logic line.
+Or we may have a mechanical device that has a different 
+failure mode behaviour for say, differnet ambient pressures or temperatures.
+
+If $E$ is the number of applied states or environmental conditions to consider
+in a system, the job of the bottom-up analyst is complicated by a cross product factor again 
+$$(N-1) \times N \times K \times E$$.
+
+If we were to consider multiple simultaneous failure modes
+we have yet another complication cross product.
+
+For instance for looking at double simultaneous failure modes 
+the equation reads $$(N-2) \times (N-1) \times N \times K \times E$$.
+
+The bottom-up methodologies FMEA, FMECA and FMEDA take single failure modes and link them
+to SYSTEM level failure modes. Because of the number of possible interactions that
+must be missed, we can term this analysis a `leap of faith' from the 
+component failure mode to the SYSTEM level.
+
+
 
 \paragraph{Ideal Static failure mode methodology}
 An ideal Static failure mode methodology would build a failure mode model
@@ -365,7 +425,7 @@ further into the way the system works and is built.
 
 \paragraph{Design Decision: Methodology must be bottom-up.}
 In oder to ensure that all component failure modes are handled,
-this methodology must statrt at the bottom, with base component failure modes.
+this methodology must start at the bottom, with base component failure modes.
 In this way automated checking can be applied to all component failure modes
 to ensure none have been inadvertantly excluded from the process.
 
@@ -378,7 +438,14 @@ with a bottom up technique.
 
 By taking components that form {\fg}s from the bottom up
 and then taking those to form higher level
-{\fg}s we can mimic the analysis process from the bottom up.
+{\fg}s we can get a close approximation of the de-composition process from the bottom up.
+The philosophy of top down de-compositon is very similar.
+Top down de-compositon applies functional 
+de-composition, because it seeks to break the system down
+into manageable and separatetly testable entities.
+A second justification for this is that the design process for a product requires both top down and bottom-up
+thinking.
+
 
 \paragraph{Problem with functional group hierarchy}
 A hierarchy of functional grouping, leading to a system model
@@ -391,10 +458,24 @@ to SYSTEM level errors. This is the `possibility to miss failure mode effects
 at SYSTEM level' critism of the FTA, FMEDA and FMECA methodologies.
 
 \paragraph{Design Decision: Methodolgy must reduce and collate errors at each functional group stage.}
-SYSTEMS typically have far fewer failure modes then the sum of its comonent failure modes.
-Many SYSTEM level errors may be caused by a variety of component level errors.
-At each fucntional group collection, there must be a process to collect
+SYSTEMS typically have far fewer failure modes then the sum of their component failure modes.
+SYSTEM level failures may be caused by a variety of component failure modes.
+A SYSTEM level failure mode is an abstracted failure mode, in that
+it is a symptom of some lower level failure or failures.
+% ABSTRACTION
+For instance a failed resistor in a sensor at a base component level is a specific 
+failure mode. For example it could be called `RESISTOR 1 OPEN'. 
+Its symptom in a functional group comprising the sensor channel that reads from it may be more abstract.
+We might call it `READING~HIGH' perhaps. At a higher level still
+this may be called `SENSOR CHANNEL 1' fault.
+At a system level it may simply be a `SENSOR FAILURE'.
+As we traverse up the fault tree the failure modes
+become more abstract. 
+%
+At each functional group collection, there must be a process to collect
 common symptoms and reduce the number of failure modes to handle.
+This must be a process that incrementally reduces the number
+of failure modes as the abstraction level reaches the SYSTEM level.
 
 \paragraph{How to build a meaningful SYSTEM failure behaviour model.}
 The next problem is how to we build a failure mode model

fmmd_design_aide/fmmd_design_aide.tex

@@ -220,7 +220,7 @@ both states of the transistor, ON and OFF.
 
 \begin{figure}[h]
  \centering
- \includegraphics[width=200pt,keepaspectratio=true]{./mv_opamp_circuit2.png}
+ \includegraphics[width=200pt,keepaspectratio=true]{./fmmd_design_aide/mv_opamp_circuit2.png}
  % mv_opamp_circuit2.png: 577x479 pixel, 72dpi, 20.35x16.90 cm, bb=0 0 577 479
  \caption{Amplifier with check circuit}
  \label{fig:mvamp2}

symptom_ex_process/algorithm.tex

@@ -312,9 +312,9 @@ $$ atc(TC) = R $$
 \begin{algorithmic}[1]
  \STATE  { let r be a `test case result'}
  \STATE  { Let the function $Analyse : tc \rightarrow r $ } \COMMENT { This analysis is a human activity, examining the failure~modes in the test case and determining how the functional~group will fail under those conditions}
- \FORALL { Environmental and Specific Conditions }
  \STATE  { $ R $ is a set of test case results $r_j \in R$ where the index $j$ corresponds to $tc_j \in TC$}
  \FORALL { $tc_j \in TC$ } 
+   \FORALL { Environmental and Specific Applied States }
      \STATE { $ rc_j = Analyse(tc_j) $} \COMMENT {this is Fault Mode Effects Analysis (FMEA) applied in the context of the functional group}
      %\STATE { $ rc_j \in R $ } \COMMENT{Add $rc_j$ to the set R}
      \STATE{ $ R := R \cup rc_j $ } \COMMENT{Add $rc_j$ to the set R}

symptom_ex_process/process.tex

@@ -27,6 +27,22 @@ the test case conditions, defined in 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}
+
+Each test case must be considered in the light of any applied states or
+environmental conditions that it may be exposed to.
+
+A {\fg} may, in the case of an electronic circuit have
+applied states. For instance test modes, shutdown or lockout modes etc.
+which are inputs to the circuit.
+In this case each test case from the {\fg} must be analysed with
+respect to all these states.
+
+A mechanical device may be required to work in different
+temperature or pressure ranges for instance and its failure mode behaviour may
+change due to enviromental factors.
+
+
 
 
 \paragraph{Symptom Identification}

symptom_ex_process/sys_abs.tex

@@ -29,6 +29,20 @@ The aim of this analysis is to find out how the functional~group reacts
 to each of the test case conditions.
 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}
+
+Each test case must be considered in the light of any applied states or
+environmental conditions that it may be exposed to.
+
+A {\fg} may, in the case of an electronic circuit have 
+applied states. For instance test modes, shutdown or lockout modes etc.
+which are inputs to the circuit.
+In this case each test case from the {\fg} must be analysed with
+respect to all these states.
+
+A mechanical device may be required to work in different 
+temperature or pressure ranges for instance and its failure mode behaviour may 
+change due to enviromental factors.