red panned and edited

component_failure_modes_definition/component_failure_modes_definition.tex

@@ -34,6 +34,14 @@ build hierarchical bottom-up models of failure mode behaviour.
 \section{ What is a Component ?}
 
 
+\begin{figure}[h]
+ \centering
+ \includegraphics[width=400pt,bb=0 0 437 141,keepaspectratio=true]{component_failure_modes_definition/component.jpg}
+ % component.jpg: 437x141 pixel, 72dpi, 15.42x4.97 cm, bb=0 0 437 141
+ \caption{A Component and its Failure Modes}
+ \label{fig:component}
+\end{figure}
+
 Let us first define a component. This is anything we use to build a 
 product or system with. This could be something quite complicated 
 like an integrated microcontroller, or quite simple like the humble resistor.
@@ -56,16 +64,9 @@ each failure mode is referenced back to only one component.
 % by the component ?
 
 
-\begin{figure}[h]
- \centering
- \includegraphics[width=400pt,bb=0 0 437 141,keepaspectratio=true]{component_failure_modes_definition/component.jpg}
- % component.jpg: 437x141 pixel, 72dpi, 15.42x4.97 cm, bb=0 0 437 141
- \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
+kept in a `parts list'. For 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}.
@@ -100,12 +101,12 @@ 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 
+The components to include in a  functional group are chosen by a human, the analyst.
+We can term this a `Functional~Group' and represent it as a class. 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.
+in it and determine a failure mode behaviour for that group.
 Or in other words we can determine the failure modes of the functional
-group. By working from the bottom up we can ensure that
+group. 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.
 
@@ -113,20 +114,22 @@ 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,
+all the failure modes of all the components 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 to do this the analyst
-must 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 
+%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 to do this the analyst
+%must consider all the failure modes of the components in the functional
+%group.
+The newly created derived~component requires a set of failure modes of its own.
+These failure modes are the failure mode behaviour of the fungtional group that it was derived from.
+Because these new failure modes were determined from a derived component we can call 
 these `derived~failure~modes'.
-It then creates a new derived~component object, and associates it to this new set of 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.
 
@@ -140,14 +143,6 @@ We can represet this using an UML diagram in figure \ref{fig:cfg}
  \caption{UML Meta model for FMMD hierarchy}
  \label{fig:cfg}
 \end{figure}
-% 
-% \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}
 
@@ -158,7 +153,7 @@ 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
+So a derived component built from base level or parts list components
 would have a level of 1.
 %\clearpage
 
@@ -180,169 +175,10 @@ functional group and converts it into a new component.
 $$ \bowtie ( FG ) \mapsto DerivedComponent $$
 
 
-% 
-% \subsection{Systems, functional groups, sub-systems and failure modes}
-% 
-% It is helpful here to define some terms, `system', `functional~group', `component', `base~component' and `sub-system'.
-% 
-% A System, is really any coherent entity that would be sold as a safety critical product.
-% A sub-system is a  part of some larger system.
-% For instance a stereo amplifier separate is a sub-system. The 
-% whole Sound System, consists perhaps of the following `sub-systems': 
-% 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.
-% 
-% A sub-system will be composed of component parts, which
-% may themselves be sub-systems.
-% 
-% Eventually by a recursive downwards process we would be able to identify
-% sub-systems built from base component parts.
-% Each `component part'
-% will have a known fault/failure behaviour.
-% That is to say, each base component has a set of known
-% ways in which it can fail.
-% 
-% If we look at the sound system again as an
-% example; the CD~player could fail in serveral distinct ways, no matter
-% what has happened to it or has gone wrong inside it.
-% 
-% A top down approach has an intrinsic problem in that we cannot guess
-% every possible failure mode at the SYSTEM level.
-% Using the reasoning that working from the bottom up forces the consideration of all possible
-% component failures (which could be missed in a top~down approach)
-% we are presented with a problem. Which initial collections of base components should we choose ?
-% 
-% For instance in the CD~player example; to start at the bottom; we are presented with
-% a massive list of base~components, resistors, motors, user~switches, laser~diodes all sorts !
-% Clearly, working from the bottom~up we need to pick small
-% collections of components that work together in some way.
-% These are termed `functional~groups'. For instance the  circuitry that powers the laser diode
-% 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.
-% 
-% 
-% In choosing the lowest level (base component) sub-systems we would look 
-% for the smallest `functional~groups' of components within a system. A functional~group is a set of components that interact
-% to perform a specific function.
-% 
-% When we have analysed the fault behaviour of a functional group, we can treat it as a `black box'.
-% We can now call our functional~group a sub-system. The goal here is to  know how will behave under fault conditions !
-% %Imagine buying one such `sub~system'  from a very honest vendor.
-% %One of those sir, yes but be warned it may fail in these distinct ways, here
-% %in the honest data sheet the set of failure modes is listed!
-% This type of thinking is starting to become more commonplace in product literature, with the emergence
-% of reliability safety standards such as IOC1508\cite{sccs},EN61508\cite{en61508}.
-% FIT (Failure in Time - expected number of failures per billion hours of operation) values
-% are published for some micro-controllers. A micro~controller
-% is a complex sub-system in its self and could be considered a `black~box' with a given reliability.
-% \footnote{Microchip sources give an FIT of 4 for their PIC18 series micro~controllers\cite{microchip}, The DOD
-% 1991 reliability manual\cite{mil1991} applies a FIT of 100 for this generic type of component}
-% 
-% As electrical components have detailed datasheets a useful extension of this would
-% be failure modes of the component, with environmental factors and MTTF statistics.
-% 
-% Currently this sort of information is generally only  available for generic component types\cite{mil1991}.
-% 
-%  
-% %At higher levels of analysis, functional~groups are pre-analysed sub-systems that interact to
-% %erform a given function.
-% 
-% %\vspace{0.3cm}
-% \begin{table}[h]
-% \begin{tabular}{||l|l||} \hline \hline
-%   {\em Definition } & {\em Description}    \\ \hline
-% System & A product designed to  \\
-%        & work as a coherent entity  \\  \hline   
-% Sub-system & A part of a system, \\
-%            & sub-systems may contain sub-systems \\    \hline 
-% Failure mode & A way in which a System, \\
-%              & Sub-system or component can fail \\     \hline  
-% Functional Group & A collection of sub-systems and/or \\
-%                  & components that interact to \\
-%                  & perform a specific function  \\    \hline  
-% Failure Mode     & The collection of all failure \\
-% Group            & modes from all the members of a \\
-%                  & functional group \\ \hline
-% Derived      & A failure mode determined from the analysis \\
-% Failure mode & of a `Failure Mode Group' \\ \hline
-% Base Component & Any bought in component, which \\
-%                & hopefully has a known set of failure modes  \\    \hline  
-%  \hline
-% component_failure_modes_definition/
-% \end{tabular}
-% \label{tab:def}
-% \caption{Table of FMMD definitions}
-% \end{table}
-% %\vspace{0.3cm}
-% 
-% \section{A UML Model of terms introduced}
-% 
-% 
-% \begin{figure}[h]
-%  \centering
-%  \includegraphics[width=350pt,bb=0 0 680 500,keepaspectratio=true]{component_failure_modes_definition/fmmd_uml.jpg}
-%  % fmmd_uml.jpg: 680x500 pixel, 72dpi, 23.99x17.64 cm, bb=0 0 680 500
-%  \caption{UML respresentation of Failure Mode Data types}
-%  \label{fig:fmmd_uml}
-% \end{figure}
-% 
-% The diagram in figure \ref{fig:fmmd_uml}
-% shows the relationships between the terms defined in table \ref{tab:def} as classes in a UML model.
-% We can start with the functional group. This is a minimal collection
-% of components that perform a simple given function.
-% For our audio separates rig, this could be 
-% the compoents that supply power to the laser diode.
-% From the `Functional~Group' we can now collect
-% all the `failure modes of the `components', and 
-% produce a `Failure~Mode~Group'. This
-% has a reference to the `Functional~Group', and is a collection
-% of `failure modes.
-% By analysing the effects of the failure modes in the `Failure~Mode~Group'
-% we can determine the failure mode behaviour of the functional group.
-% This failure mode behaviour is a collection of derived failure modes.
-% We can now consider the Functional group as a component now, because
-% we have a set of failure modes for it.
-% 
-% \subsection{Sub-System Class Definition}
-% A sub-system can be defined by the classes used to create it, and 
-% its set of derived failure modes.
-% In this way sub-systems naturally form trees, with the lower most leaf nodes being
-% base components.
-% Note that the UML model is recursive. We can build functional groups using sub-systems
-% as components. This UML model naturally therefore, forms a hierarchy
-% of failure mode analysis, which has a one top level entry, that being the SYSTEM.
-% The TOP level entry will determine the failure modes 
-% for the product/system under analysis.
-% 
-% \subsection{Refining the UML model to use inheritance}
-% We can refine this model a little by noticing that a system is merely the 
-% top level sub-system. We can thus have System inherit sub-system.
-% A derived failure mode, is simply a failure mode at a higher level of analysis
-% it can therefore inherit `failure\_mode'.
-% 
-% The modified UML diagram using inheritance is figure \ref{fig:fmmd_uml2}.
-% \begin{figure}[h]
-%  \centering
-%  \includegraphics[width=350pt,bb=0 0 877 675,keepaspectratio=true]{./fmmd_uml2.jpg}
-%  % fmmd_uml2.jpg: 877x675 pixel, 72dpi, 30.94x23.81 cm, bb=0 0 877 675
-%  \caption{UML Representation of Failure Mode Data Types}
-%  \label{fig:fmmd_uml2}
-% \end{figure}
-% % 
-% % \begin{figure}[h]
-% %  \centering
-% %  \includegraphics[width=350pt,bb=0 0 680 500,keepaspectratio=true]{component_failure_modes_definition/fmmd_uml2.jpg}
-% %  % fmmd_uml.jpg: 680x500 pixel, 72dpi, 23.99x17.64 cm, bb=0 0 680 500
-% %  \caption{UML respresentation of Failure Mode Data types}
-% %  \label{fig:fmmd_uml2}
-% % \end{figure}
-
 
 \section{Unitary State Component Failure Mode sets}
 
+\paragraph{Design Descision/Constraint}
 An important factor in defining a set of failure modes is that they
 should be as clearly defined as possible.
 It should not be possible for instance for
@@ -362,7 +198,7 @@ within one package.
 \begin{definition}
 A set of failure modes where only one fault mode
 can be active at a time is termed a `unitary~state' failure mode set.
-This is termed the $U$ set thoughout this study.
+%This is termed the $U$ set thoughout this study.
 This corresponds to the `mutually exclusive' definition in 
 probability theory\cite{probandstat}.
 \end{definition}