after Friday meeting with Andrew Fish

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -47,8 +47,13 @@ failure rates)\cite{mil1991}. For instance, a simple resistor is generally consi
 to fail in two ways, it can go open circuit or it can short.  
 Thus we can associate a set of faults to this component $ResistorFaultModes=\{OPEN, SHORT\}$.
 The UML diagram in figure 
-\ref{fig:component} shows a component as a simple data
-structure with its failure modes.
+\ref{fig:component} shows a component as a data
+structure with its associated failure modes.
+From this diagram we see that each component must have at least one failure mode.
+Also to clearly show that the failure modes are unique events associated with one component,
+each failure mode is referenced back to only one component.
+% Perhaps talk here about the failure modes being shared, but by being referenced
+% by the component ?
 
 
 \begin{figure}[h]
@@ -59,14 +64,6 @@ structure with its failure modes.
  \label{fig:component}
 \end{figure}
 
-% \begin{figure}[h+]
-%  \centering
-%  \includegraphics[width=400pt,bb=0 0 433 68,keepaspectratio=true]{component_failure_modes_definition/component.jpg}
-%  % component.jpg: 433x68 pixel, 72dpi, 15.28x2.40 cm, bb=0 0 433 68
-%  \caption{A Component and its failure modes}
-%  \label{fig:component}
-% \end{figure}
-
 A product naturally consists of many components and these are traditionally
 kept in a `parts list'. For safety critical product this is a usually formal document
 and is used by quality inspectors to ensure the correct parts are being fitted.
@@ -96,39 +93,77 @@ determine the likelihood of component failures
 causing specific system level errors (see Bayes theorem \ref{bayes}).
 Another top down technique is to apply cost benifit analysis 
 to determine which faults are the highest priority to fix\cite{FMEA}.
-The aim of this study is to produce complete  failure
+The aim of FMMD analysis is to produce complete  failure
 models of safety critical systems  from the bottom-up,
 starting, where possible with known component failure modes.
 
 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 for the functional groups are chosen by a human, the analyst.
 We can term this a `Functional~Group'. When we have a 
 `Functional~Group' we can look at the failure modes of all the components
 in it and decide how these will affect the Group.
 Or in other words we can determine the failure modes of the functional
-group. These new failure modes are derived from the functional group, we can therefore call 
-these `derived failure modes'.
-We now have something very useful, because
-we can now treat this functional group as a component with a known set of failure modes.
-This newly derived component can be used as a higher level
-building block for the system we are analysing. 
-Derived components, can be used
-to form higher level functional groups.
-This process can continue until have build a hierarcy that converges to a failure model of the entire system.
-To differentiate the components derived from functional groups, we can
-add a new attribute to the class `Component', that of analysis
-level. The UML representation shows a `functional group' having a one to one relationship with a derived component.
+group. By working from the bottom up we can ensure that
+all component failure modes must be considered. A top down approach
+could miss individual failure modes of components.
+
+
+\subsection{From functional group to newly derived component}
+
+The process for taking a functional~group, considering
+all the failure modes of all the componentsin figure \ref{fig:cfg} in it,
+and analysing these is called `symptom abstraction' and 
+is dealt with in detail in chapter \ref{symptom_abstraction}.
+
+In terms of our UML model the symptom abstraction process takes a functional~group,
+and creates a new derived component from it.
+To do this it first creates
+a new set of failure modes, representing the fault behaviour
+of the functional group. This is a human process and the analyst
+will consider all the failure modes of the components in the functional
+group.
+These new failure modes are derived from the functional group, we can therefore call 
+these `derived~failure~modes'.
+It then creates a new derived~component object, and associates it to this new set of derived~failure~modes.
+We thus have a `new' component, or system building block, but with a known and traceable
+fault behaviour.
+
+The UML representation shows a `functional group' having a one to one relationship with a derived~component.
 We can represet this using an UML diagram in figure \ref{fig:cfg}
 
 \begin{figure}[h]
  \centering
- \includegraphics[width=400pt,bb=0 0 712 235,keepaspectratio=true]{component_failure_modes_definition/cfg.jpg}
- % cfg.jpg: 712x205 pixel, 72dpi, 25.12x7.23 cm, bb=0 0 712 205
- \caption{Components Derived from Functional Groups}
+ \includegraphics[width=400pt,bb=0 0 712 286,keepaspectratio=true]{./cfg.jpg}
+ % cfg.jpg: 712x286 pixel, 72dpi, 25.12x10.09 cm, bb=0 0 712 286
+ \caption{UML Meta model for FMMD hierarchy}
  \label{fig:cfg}
 \end{figure}
-\clearpage
+% 
+% \begin{figure}[h+]
+%  \centering
+%  \includegraphics[width=400pt,bb=0 0 712 235,keepaspectratio=true]{component_failure_modes_definition/cfg.jpg}
+%  % cfg.jpg: 712x205 pixel, 72dpi, 25.12x7.23 cm, bb=0 0 712 205
+%  \caption{Components Derived from Functional Groups}
+%  \label{fig:cfg}
+% \end{figure}
+
+\subsection{Keeping track of the dereived components position in the hierarchy}
+
+The UML meta model in figure \ref{fig:cfg}, will build a hierarchy of
+objects, with derived~components forming functional~groups, and creating
+derived components higher up in the structure.
+The level variable in each Component,
+indicates the position in the hierarchy. Base or parts~list components
+have a `level' of 0. Derived~components take a level based on the highest level
+component used to build the functional group it was derived from plus 1.
+So a derived component built from base lavel or parts list components
+would have a level of 1.
+%\clearpage
+
+
+
 \section{Set Theory Description}
 
 $$ System \stackrel{has}{\longrightarrow} PartsList $$
@@ -362,17 +397,26 @@ therefore
 $$ FM(R) \in U $$
 
 
-We can make this a general case by taking a set $C$ (where $c1, c2 \in C$) representing a collection
+We can make this a general case by taking a set $F$ (where $f1, f2 \in F$) representing a collection
 of component failure modes.
-We can now state that
+We can define a boolean function {\ensuremath{\mathcal{ACTIVE()}}} that returns 
+whether the fault mode is active (true) or dormant (false).
+
+We can say that if any pair of fault modes is active at the same time, then the failure mode set is not
+unitary state:
+we state this formally
+ \begin{equation}
+  \forall f_1,f_2 \in F \dot ( f_1 \neq f_2 \wedge \mathcal{ACTIVE}({f_1}) \wedge \mathcal{ACTIVE}({f_2}) ) \implies F \not\in U 
+ \end{equation}
 
 
-\begin{equation}
- c1 \cap c2 \neq \emptyset  | c1 \neq c2 \wedge c1,c2 \in C \wedge C \not\in U
-\end{equation}
+% 
+% \begin{equation}
+%  c1 \cap c2 \neq \emptyset  | c1 \neq c2 \wedge c1,c2 \in C \wedge C \not\in U
+% \end{equation}
 
 That is to say that it is impossible that any pair of failure modes can be active at the same time
-for the failure mode set $C$ to exists in the family of sets $U$
+for the failure mode set $F$ to exists in the family of sets $U$
 
 Note where that are more than two failure~modes, 
 by banning pairs from being active at the same time
@@ -383,8 +427,8 @@ we have banned larger combinations as well.
 \section{Component Failure Modes and Statistical Sample Space}
 %\paragraph{NOT WRITTEN YET PLEASE IGNORE}
 A sample space is defined as the set of all possible outcomes.
-Here the outcomes we are interested in are the failure modes 
-of the component.
+For a component this set of all possible outcomes are its normal correct
+operating state and all its failure modes.
 When dealing with failure modes, we are not interested in 
 the state where the component is working perfectly or `OK' (i.e. operating with no error).
 We are interested only in ways in which it can fail.