diff --git a/component_failure_modes_definition/component_failure_modes_definition.tex b/component_failure_modes_definition/component_failure_modes_definition.tex index d580139..83ed3d4 100644 --- a/component_failure_modes_definition/component_failure_modes_definition.tex +++ b/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}