From a47f78cde601e5d5f920165ff96d7d1ee85224ad Mon Sep 17 00:00:00 2001 From: Robin Clark Date: Tue, 23 Jul 2013 21:52:48 +0100 Subject: [PATCH] skicat till jmc for lasning.... sen skicker den till javla lat hundar --- submission_thesis/CH4_FMMD/copy.tex | 2 +- submission_thesis/CH8_Conclusion/copy.tex | 2 +- submission_thesis/appendixes/algorithmic.tex | 599 ++++++++++--------- 3 files changed, 306 insertions(+), 297 deletions(-) diff --git a/submission_thesis/CH4_FMMD/copy.tex b/submission_thesis/CH4_FMMD/copy.tex index 85a30f0..38d963b 100644 --- a/submission_thesis/CH4_FMMD/copy.tex +++ b/submission_thesis/CH4_FMMD/copy.tex @@ -1163,7 +1163,7 @@ to which we are approving/analysing a system. %% FIDDLINGING STEREO SUB_SYSTEM EXAMPLE, THE FIDDLINGING CHILDRENS SECTION \subsection{Definition of terms: sound system example.} - +\label{sec:cdplayer} %000000elpful here to define the terms, `system', `functional~group', `component', `base~component', `symptom' and `derived~component/sub-system'. %These are listed in table~\ref{tab:symexdef}. diff --git a/submission_thesis/CH8_Conclusion/copy.tex b/submission_thesis/CH8_Conclusion/copy.tex index c11819f..e8a741b 100644 --- a/submission_thesis/CH8_Conclusion/copy.tex +++ b/submission_thesis/CH8_Conclusion/copy.tex @@ -555,7 +555,7 @@ leak of radioactive material into the environment. % For the objective failure mode determined by FMEA, that of leakage of coolant, -we would not reasonably expect this to go unchecked/resolved for an extended period and cause such a critical failure. +we would not reasonably expect this to go unchecked and unresolved for an extended period and cause such a critical failure. % The criticality level is therefore subjective. We cannot know how the operators would have reacted, and deficiencies in the HMI were not a factor in the failure analysis. diff --git a/submission_thesis/appendixes/algorithmic.tex b/submission_thesis/appendixes/algorithmic.tex index f1cc8da..05daa25 100644 --- a/submission_thesis/appendixes/algorithmic.tex +++ b/submission_thesis/appendixes/algorithmic.tex @@ -239,9 +239,9 @@ an algorithmic context. \glossary{name={system}, description={A product designed to work as a coherent entity}} \glossary{name={sub-system}, description={A part of a system, sub-systems may contain sub-systems and so-on}} -\glossary{name={derived component}, description={A theoretical component, derived from a collection of components (which may be derived components themselves)}} -\glossary{name={functional group}, description={A collection of sub-systems and/or components that interact to perform a specific function}} -\glossary{name={symptom}, description={A failure mode of a functional group (of components), caused by a combination of its component failure modes}} +\glossary{name={{\dc}}, description={A theoretical component, derived from a collection of components (which may be derived components themselves)}} +\glossary{name={{\fg}}, description={A collection of sub-systems and/or components that interact to perform a specific function}} +\glossary{name={symptom}, description={A failure mode of a {\fg}, caused by a combination of its component failure modes}} \glossary{name={base component}, description={Any bought in component, or lowest level module/or part}} %\glossary{name={entry name}, description={entry description}} @@ -270,10 +270,10 @@ The FMMD process is described in chapter~\ref{sec:chap4}, to re-cap, FMMD has fo % with its own set of failure modes. This process allows us to modularise and simply FMEA analysis of systems. % -The FMEA process is described in greater detail below. +The FMMD process stages are expanded upon below. -\paragraph{FMEA applied to the Functional Group.} +\paragraph{FMEA applied to the {\fg}.} As a {\fg} is a set of components, the failure~modes that we have to consider are the failure modes of its components. %, as @@ -295,7 +295,7 @@ In other words, if a designer has a previously analysed module to use, he need n the failure modes of its components: it is handed it as a derived component, which has its own FMMD defined set of failure modes. % symptoms. % -The designer can now treat this module as a black box, or {\dc}. +The designer can now treat this module as a black box (i.e. as a {\dc}). \paragraph{Environmental Conditions or Operational States.} @@ -332,10 +332,10 @@ When all `test~cases' have been analysed, a second phase can be actioned. % appl 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. %Single component failures (or combinations) within the functional~group may cause unique symptoms. %However, m -Many failures, when looked at from the perspective of the functional group, will have the same symptoms. +Many failures, when looked at from the perspective of the {\fg}, will have the same symptoms. These can be collected as `common symptoms'. % -To go back to the CD~player example, a failed +To go back to the CD~player example from section~\ref{sec:cdplayer}, a failed output stage, and a failed internal audio amplifier, will both cause the same failure symptom; $no\_sound$ ! @@ -382,10 +382,10 @@ It is possible here for an automated system to flag un-handled failure modes. %\paragraph{To analyse a base level Derived~Component/sub-system} -To summarise: +The expanded FMMD process can now be described in eight stages: -\begin{itemize} - \item Choose a set of components to form a functional group. +\begin{enumerate} + \item Choose a set of components to form a {\fg}. % \item Obtain the list of components in the functional group \item Collect the failure modes of each component into a flat set. \item Choose all single instances (and optional selected combinations\footnote{ @@ -398,7 +398,7 @@ form `test~cases'. % \item Where simultaneous 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 the failure~mode behaviour of the functional group. +we determine the failure~mode behaviour of the {\fg}. % This is a human process, applying FMEA for each test case. % @@ -411,269 +411,277 @@ for each test case. i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail. % \item A new `{\dc}' can now be created where each common~symptom, or lone symptom, is a failure~mode of this new component. -\end{itemize} +\end{enumerate} +% +% \ifthenelse {\boolean{paper}} +% { +% \section{A theoretical `Derived Component' example} +% Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. +% +% $$ FG = \{ C_1 , C_2 , C_3 \} $$ +% +% Each component has a set of related fault modes (i.e. ways in which it can fail to operate correctly). +% Let us define the following failure modes for each component, defining a function $fm()$ +% that is passed a component and returns the set of failure modes associated with it +% \footnote{Base component failure modes are defined, often with +% statistics and environmental factors in a variety of sources. \cite{mil1991} +% }. +% +% +% \subsection{Define Failure mode function $fm$} +% +% Let the set of all possible components be $\mathcal{C}$ +% and let the set of all possible failure modes be $\mathcal{F}$. +% +% We can define a function $fm$ +% +% \begin{equation} +% {fm} : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F} +% \end{equation} +% +% defined by (where $C$ is a component and $F$ is a set of failure modes): +% +% $$ fm ( C ) = F $$ +% +% %\\ +% e.g. +% %And for this example: +% +% $$ fm(C_1) = \{ a_1, a_2, a_3 \} $$ +% $$ fm(C_2) = \{ b_1, b_2 \} $$ +% $$ fm(C_3) = \{ c_1, c_2 \} $$ +% +% where $a_n,b_n,c_n$ are component failure modes. +% +% \paragraph{Finding all failure modes within the functional group} +% +% For FMMD failure mode analysis, we need to consider the failure modes +% from all the components in the functional group as a flat set. +% This can be found by applying function $fm$ to all the components +% in the functional~group and taking the union of them (where F is the set of all failure modes for all components in the functional group) thus: +% +% $$ F = \bigcup_{j \in \{1...n\}} fm(C_j) $$ +% +% We overload the notation for the function $fm$ +% and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: +% +% \begin{equation} +% fm : FG \rightarrow \mathcal{F} +% \end{equation} +% +% Applied to the functional~group $FG$ in the example above: +% \begin{equation} +% fm(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}. +% \end{equation} +% +% This can be seen as all the failure modes that can affect the failure mode group $FG$. +% +% \subsection{Analysis of the functional group failure modes} +% +% \label{theoreticalsx} +% For this example we shall consider single failure modes. +% %For each of the failure modes from $fm(FG)$ we shall +% %create a test case ($g_i$). Next each test case is examined/analysed +% %and its effect on the functional group determined. +% +% \par +% %\vspace{0.3cm} +% \begin{table}[h] +% \begin{tabular}{||c|c|c|c||} \hline \hline +% {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ +% {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline +% % +% $a\_1$ & $fs\_1$ & $g_{1}$ & SP2 \\ \hline +% $a\_2$ & $fs\_2$ & $g_{2}$ & SP1 \\ \hline +% $a\_3$ & $fs\_3$ & $g_{3}$ & SP2\\ \hline +% $b\_1$ & $fs\_4$ & $g_{4}$ & SP1 \\ \hline +% $b\_2$ & $fs\_5$ & $g_{5}$ & SP1 \\ \hline +% $c\_1$ & $fs\_6$ & $g_{6}$ & SP3 \\ \hline +% $c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline +% % +% \hline +% \end{tabular} +% \caption{Component to functional group to failure symptoms example} +% \label{tab:fexsymptoms} +% \end{table} +% %\vspace{0.3cm} +% +% Table~\ref{tab:fexsymptoms} shows the analysis process. +% As we are only looking at single fault possibilities for this example each test case +% is represented by one failure mode. +% Chosen combinations of component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes.}. +% The test cases are analysed w.r.t. the functional~group. +% These become functional~group~failure~modes ($g$'s). +% The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. +% +% For the sake of example, let us consider the fault symptoms of the {\fg} $FG$ to be $\{g_2, g_4, g_5\}$ +% As failure modes, these are +% identical from the perspective of the functional~group. +% That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_5$ % failure modes +% occur, is going to be the same. +% For example, in our CD player example, this could mean the common symptom `no\_sound'. +% No matter which component failure modes, or combinations thereof cause the problem, +% the failure symptom is the same. +% It may be of interest to the manufacturers and designers of the CD player why it failed, but +% as far as we, the users, are concerned it has only one symptom, +% `no\_sound'! +% We can thus group these component failure modes into a common symptom, $SP1$, thus +% $ SP1 = \{g_2, g_4, g_5\}$. +% % These can then be joined to form a spider. +% Likewise +% let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure~mode {\em from the perspective of the functional~group}. +% Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}, +% but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$. +% +% We now have in $SP1$, $SP2$ and $SP3$ the three ways in which this functional~group can fail. +% In other words we have derived failure modes for this functional~group. +% We can place these in a set of symptoms. +% % +% $$ SP = \{ SP1, SP2, SP3 \}. $$ +% % +% % +% These three symptoms can be considered the set of failure modes for the functional~group, if +% we treat it as though it were a {\em black box} +% or a {\em component} to be used in higher level designs. +% % +% The next stage of the process could be applied automatically. +% Each common symptom becomes a failure mode of +% a newly created derived component. Let $DC$ be the newly derived component. +% This is assigned the failure modes that were derived from the functional~group. +% 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 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 ? +% % This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! +% % +% %\ifthenelse {\boolean{paper}} +% %{ +% An advantage of a bottom-up process is that failure modes +% 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{sec:aims}). +% %} +% % +% This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component +% with known failure modes +% (although at a higher level of abstraction). +% This process can be repeated using {\dcs} to build a +% hierarchical fault~mode model. +% The newly derived component $DC$ is available for use to form higher level functional groups, and we can thus +% consider DC as being in the set of components i.e. $DC \in \mathcal{C}$ +% +% %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% +% +% \subsection{Defining the analysis process as a function} +% +% We define one stage of the FMMD process, taking a {\fg} and deriving a {\dc} +% by the symbol `D'. +% Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$ +% is the set of all derived components, we can define the symptom abstraction process thus: +% $$ +% %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent +% \derivec : \mathcal{FG} \rightarrow \mathcal{DC} . +% $$ +% +% Given by +% $ \derivec ( FG ) = DC $ +% as per the example in precedeing section \ref{theoreticalsx}. +% +% \paragraph{Extending $\derivec$ to {\dcs}} +% +% It is useful to further define the $\derivec$ function, to +% take the failure modes from derived components (as well as base components) +% and return a new derived component. +% This generalises the function $\derivec$ and allows us to build +% hierarchical failure mode models. +% +% Where a {\fg} is composed of derived components, for sake of example +% where $DC_1, DC_2, DC_3 $ are {\dc}s we could collect these into a {\fg} thus +% $FG_{derived} = \{ DC_1, DC_2, DC_3 \}$. +% +% $DCFM$ is a set of failure modes from the new {\fg} $FG_{derived},$ +% $DCFM = fm(FG_{derived})$. +% +% We can apply the symptom abstraction process $\derivec$ +% to the {\fg} comprised of derived components +% because we can obtain a failure mode set, +% (the failure mode set we have named $DCFM$). +% +% Thus we can now move up another abstraction level by applying +% symptom abstraction to the {\fg} +% $FG_{derived}$ shown in equation \ref{eqn:fgderived}. +% +% \begin{equation} +% \label{eqn:fgderived} +% \derivec ( FG_{derived} ) = DC_{derived} +% \end{equation} +% +% +% The case +% where a {\fg} has been created from {\dcs} +% using function `$\derivec$' leads us to +% {\dc}s at a higher level of failure mode abstraction. +% A notation will be described in the next section +% to keep track of the abstraction level of a {\dc}. +% +% %%$$ +% %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent +% %%\derivec : FG_{derived} \rightarrow DC +% %%$$ +% % +% %\begin{equation} +% % \derivec(FG_{cfm}) = DC +% %\end{equation} +% % +% %or applying the function $fm$ to obtain the $FG_{cfm}$ set +% % +% %%To put this in context, where FG is a functional group, sourced from base or derived components, +% %%we may state the process of +% %%analysing the failure modes in the {\fg} and returning a {\dc} thus: +% %%\begin{equation} +% %% \derivec((FG)) = DC +% %%\end{equation} +% +% +% In other words by analysing a functional group containing derived components, +% we have a new derived component as our result. +% This naturally +% builds a bottom-up failure mode model and +% with each iteration the model becomes more abstract will eventually reach +% the SYSTEM level. +% +% %The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour. +% %The derivation of $SS_{fm}$ is represented graphically using the `$\derivec$' symbol, as in figure \ref{fig:gensubsys4} +% +% % \begin{figure}[h+] +% % \centering +% % \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} +% % % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 +% % \label{fig:gensubsys3} +% % \caption{Deriving a new diagram} +% +% %% IF this is a paper it needs work on the description here. +% } +% { -\ifthenelse {\boolean{paper}} -{ -\section{A theoretical `Derived Component' example} -Consider a functional group $FG$ with components $C_1$, $C_2$ and $C_3$. - -$$ FG = \{ C_1 , C_2 , C_3 \} $$ - -Each component has a set of related fault modes (i.e. ways in which it can fail to operate correctly). -Let us define the following failure modes for each component, defining a function $fm()$ -that is passed a component and returns the set of failure modes associated with it -\footnote{Base component failure modes are defined, often with -statistics and environmental factors in a variety of sources. \cite{mil1991} -}. +\subsection{Single FMMD stage described as a `symptom~abstraction~process'} -\subsection{Define Failure mode function $fm$} - -Let the set of all possible components be $\mathcal{C}$ -and let the set of all possible failure modes be $\mathcal{F}$. - -We can define a function $fm$ - -\begin{equation} -{fm} : \mathcal{C} \rightarrow \mathcal{P}\mathcal{F} -\end{equation} - -defined by (where $C$ is a component and $F$ is a set of failure modes): - -$$ fm ( C ) = F $$ - -%\\ -e.g. -%And for this example: - -$$ fm(C_1) = \{ a_1, a_2, a_3 \} $$ -$$ fm(C_2) = \{ b_1, b_2 \} $$ -$$ fm(C_3) = \{ c_1, c_2 \} $$ - -where $a_n,b_n,c_n$ are component failure modes. - -\paragraph{Finding all failure modes within the functional group} - -For FMMD failure mode analysis, we need to consider the failure modes -from all the components in the functional group as a flat set. -This can be found by applying function $fm$ to all the components -in the functional~group and taking the union of them (where F is the set of all failure modes for all components in the functional group) thus: - -$$ F = \bigcup_{j \in \{1...n\}} fm(C_j) $$ - -We overload the notation for the function $fm$ -and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: - -\begin{equation} -fm : FG \rightarrow \mathcal{F} -\end{equation} - -Applied to the functional~group $FG$ in the example above: -\begin{equation} - fm(FG) = \{a_1, a_2, a_3, b_1, b_2, c_1, c_2 \}. -\end{equation} - -This can be seen as all the failure modes that can affect the failure mode group $FG$. - -\subsection{Analysis of the functional group failure modes} - -\label{theoreticalsx} -For this example we shall consider single failure modes. -%For each of the failure modes from $fm(FG)$ we shall -%create a test case ($g_i$). Next each test case is examined/analysed -%and its effect on the functional group determined. - -\par -%\vspace{0.3cm} -\begin{table}[h] -\begin{tabular}{||c|c|c|c||} \hline \hline - {\em Component Failure Mode } & {\em test case} & {\em Functional Group} & {\em Functional Group} \\ - {\em } & {\em } & {\em failure mode} & {\em Symptom} \\ \hline -% -$a\_1$ & $fs\_1$ & $g_{1}$ & SP2 \\ \hline -$a\_2$ & $fs\_2$ & $g_{2}$ & SP1 \\ \hline -$a\_3$ & $fs\_3$ & $g_{3}$ & SP2\\ \hline -$b\_1$ & $fs\_4$ & $g_{4}$ & SP1 \\ \hline -$b\_2$ & $fs\_5$ & $g_{5}$ & SP1 \\ \hline -$c\_1$ & $fs\_6$ & $g_{6}$ & SP3 \\ \hline -$c\_2$ & $fs\_7$ & $g_{7}$ & SP2\\ \hline -% - \hline -\end{tabular} -\caption{Component to functional group to failure symptoms example} -\label{tab:fexsymptoms} -\end{table} -%\vspace{0.3cm} - -Table~\ref{tab:fexsymptoms} shows the analysis process. -As we are only looking at single fault possibilities for this example each test case -is represented by one failure mode. -Chosen combinations of component failure modes become test cases\footnote{The test case stage is necessary because for more complex analysis we have to consider the effects of combinations of component failure modes.}. -The test cases are analysed w.r.t. the functional~group. -These become functional~group~failure~modes ($g$'s). -The functional~group~failure~modes are how the functional group fails for the test~case, rather than how the components failed. - -For the sake of example, let us consider the fault symptoms of the {\fg} $FG$ to be $\{g_2, g_4, g_5\}$ -As failure modes, these are -identical from the perspective of the functional~group. -That is to say, the way in which functional~group fails if $g_2$, $g_4$ or $g_5$ % failure modes -occur, is going to be the same. -For example, in our CD player example, this could mean the common symptom `no\_sound'. -No matter which component failure modes, or combinations thereof cause the problem, -the failure symptom is the same. -It may be of interest to the manufacturers and designers of the CD player why it failed, but -as far as we, the users, are concerned it has only one symptom, -`no\_sound'! -We can thus group these component failure modes into a common symptom, $SP1$, thus -$ SP1 = \{g_2, g_4, g_5\}$. -% These can then be joined to form a spider. -Likewise -let $SP2 = \{g_1, g_3, g_7\}$ be an identical failure~mode {\em from the perspective of the functional~group}. -Let $\{g_6\}$ be a distinct failure mode {\em from the perspective of the functional~group i.e. it cannot be grouped as a common symptom}, -but as a `lone' symptom it can be assigned its own symptom set $SP3 = \{g_6\}$. - -We now have in $SP1$, $SP2$ and $SP3$ the three ways in which this functional~group can fail. -In other words we have derived failure modes for this functional~group. -We can place these in a set of symptoms. -% -$$ SP = \{ SP1, SP2, SP3 \}. $$ -% -% -These three symptoms can be considered the set of failure modes for the functional~group, if -we treat it as though it were a {\em black box} -or a {\em component} to be used in higher level designs. -% -The next stage of the process could be applied automatically. -Each common symptom becomes a failure mode of -a newly created derived component. Let $DC$ be the newly derived component. -This is assigned the failure modes that were derived from the functional~group. -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 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 ? -% This is rather like a child not eating his lunch and being served it cold for dinner\footnote{Although I was only ever threatened with a cold dinner once, my advice to all nine year olds faced with this dilemma, it is best to throw the brussel sprouts out of the dining~room window while the adults are not watching!}! -% -%\ifthenelse {\boolean{paper}} -%{ -An advantage of a bottom-up process is that failure modes -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{sec:aims}). -%} -% -This sub-system or {\dc} $DC$, with its three error modes, can now be treated as a component -with known failure modes -(although at a higher level of abstraction). -This process can be repeated using {\dcs} to build a -hierarchical fault~mode model. -The newly derived component $DC$ is available for use to form higher level functional groups, and we can thus -consider DC as being in the set of components i.e. $DC \in \mathcal{C}$ - -%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% - -\subsection{Defining the analysis process as a function} - -We define one stage of the FMMD process, taking a {\fg} and deriving a {\dc} -by the symbol `D'. -Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$ -is the set of all derived components, we can define the symptom abstraction process thus: -$$ -%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent -\derivec : \mathcal{FG} \rightarrow \mathcal{DC} . -$$ - -Given by -$ \derivec ( FG ) = DC $ -as per the example in precedeing section \ref{theoreticalsx}. - -\paragraph{Extending $\derivec$ to {\dcs}} - -It is useful to further define the $\derivec$ function, to -take the failure modes from derived components (as well as base components) -and return a new derived component. -This generalises the function $\derivec$ and allows us to build -hierarchical failure mode models. - -Where a {\fg} is composed of derived components, for sake of example -where $DC_1, DC_2, DC_3 $ are {\dc}s we could collect these into a {\fg} thus -$FG_{derived} = \{ DC_1, DC_2, DC_3 \}$. - -$DCFM$ is a set of failure modes from the new {\fg} $FG_{derived},$ -$DCFM = fm(FG_{derived})$. - -We can apply the symptom abstraction process $\derivec$ -to the {\fg} comprised of derived components -because we can obtain a failure mode set, -(the failure mode set we have named $DCFM$). - -Thus we can now move up another abstraction level by applying -symptom abstraction to the {\fg} -$FG_{derived}$ shown in equation \ref{eqn:fgderived}. - -\begin{equation} -\label{eqn:fgderived} - \derivec ( FG_{derived} ) = DC_{derived} -\end{equation} - - -The case -where a {\fg} has been created from {\dcs} -using function `$\derivec$' leads us to -{\dc}s at a higher level of failure mode abstraction. -A notation will be described in the next section -to keep track of the abstraction level of a {\dc}. - -%%$$ -%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent -%%\derivec : FG_{derived} \rightarrow DC -%%$$ -% -%\begin{equation} -% \derivec(FG_{cfm}) = DC -%\end{equation} -% -%or applying the function $fm$ to obtain the $FG_{cfm}$ set -% -%%To put this in context, where FG is a functional group, sourced from base or derived components, -%%we may state the process of -%%analysing the failure modes in the {\fg} and returning a {\dc} thus: -%%\begin{equation} -%% \derivec((FG)) = DC -%%\end{equation} - - -In other words by analysing a functional group containing derived components, -we have a new derived component as our result. -This naturally -builds a bottom-up failure mode model and -with each iteration the model becomes more abstract will eventually reach -the SYSTEM level. - -%The $SS_{fm}$ set of fault modes can be represented as a diagram with each fault~mode of $SS$ being a contour. -%The derivation of $SS_{fm}$ is represented graphically using the `$\derivec$' symbol, as in figure \ref{fig:gensubsys4} - -% \begin{figure}[h+] -% \centering -% \includegraphics[width=3in,height=3in]{./symptom_abstraction4.jpg} -% % synmptom_abstraction.jpg: 570x601 pixel, 80dpi, 18.10x19.08 cm, bb=0 0 513 541 -% \label{fig:gensubsys3} -% \caption{Deriving a new diagram} - -%% IF this is a paper it needs work on the description here. -} -{ +We can view one stage of FMMD analysis as the act of symptom abstraction. +This is because we take a {\fg} and from its component failure modes and FMEA analysis, symptoms of failure derived. +These derived failure mode, failure modes of the {\fg} considered as an entity or component, are abstract +or at a higher level in the systems modular hierarchy. %To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}. The FMMD process is now described introducing set theoretical definitions % formal definitions @@ -693,7 +701,7 @@ We can define a function $fm$ %$$ fm ( C ) = F $$ We overload the notation for the function $fm$ -and define it for the set components within a functional group $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: +and define it for the set components within a {\fg} $FG$ (i.e. where $FG \subset \mathcal{C} $) thus: \begin{equation} fm : FG \rightarrow \mathcal{F} @@ -701,7 +709,7 @@ fm : FG \rightarrow \mathcal{F} -Where $\mathcal{FG}$ is the set of all sets of functional groups, and $\mathcal{DC}$ +Where $\mathcal{FG}$ is the set of all sets of {\fgs}, and $\mathcal{DC}$ is the set of all derived components, we can define the symptom abstraction process thus: $$ %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent @@ -722,7 +730,7 @@ this section %describes the symptom abstraction process using set theory and procedural descriptions. % -The {\em symptom abstraction process} (given the symbol `$\derivec$', D for derive) takes a functional group $FG$ +The {\em symptom abstraction process} (given the symbol `$\derivec$', D for derive) takes a {\fg} $FG$ and a new derived~component/sub-system $DC$. %The sub-system $SS$ is a collection %of failure~modes of the sub-system. @@ -735,7 +743,7 @@ and a new derived~component/sub-system $DC$. % as a component with a known set of failure modes. -\paragraph{Enumerating abstraction levels} +\paragraph{Enumerating abstraction levels.} \label{sec:abstractionlevel} As described in section~\ref{sec:alpha} we can assign an attribute of abstraction level $\abslev$ to components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$). @@ -743,7 +751,7 @@ For a base component, let the abstraction level be zero. If we apply the symptom abstraction process $\derivec$, the resulting derived~component will have an $\abslev$ value one higher that the highest $\abslev$ value of any of the components -in the functional group used to derive it. +in the {\fg} used to derive it. Thus a derived component sourced from base components will have an $\abslev$ value of 1. % @@ -758,7 +766,7 @@ will have an $\abslev$ value of 1. %With a derived component $DC$ having an abstraction level The attribute $\abslev$ can be used to track the level of fault abstraction of components in an FMMD hierarchy. Because base and derived components -are collected to form functional groups, a hierarchy is +are collected to form {\fgs}, a hierarchy is naturally formed with the abstraction levels increasing with each tier. \fmmdgloss @@ -785,14 +793,14 @@ $$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$ \begin{algorithm}[h+] -\caption{Derive new `Component' from Functional Group: $\derivec(FG)$} \label{alg66} +\caption{Derive new `Component' from {\fg}: $\derivec(FG)$} \label{alg66} \begin{algorithmic}[1] \STATE {F = fm (FG)} \COMMENT{ collect all component failure modes }%from the from the components in the functional~group } - \STATE {TC = dtc (F)} \COMMENT{ determine all test cases } %to apply to the functional group } - \STATE {R = atc (TC)} \COMMENT{ analyse the test cases }%, for failure mode behaviour of the functional~group } - \STATE {SP = fcs (R)} \COMMENT{ find common symptoms }%of failure for the functional group } + \STATE {TC = dtc (F)} \COMMENT{ determine all test cases giving a set of test cases $TC$ } %to apply to the functional group } + \STATE {R = atc (TC)} \COMMENT{ analyse the test cases giving a set of FMEA results $R$}%, for failure mode behaviour of the functional~group } + \STATE {SP = fcs (R)} \COMMENT{ find common symptoms, aggregate results from R giving a set of symptoms $SP$}%of failure for the functional group } \STATE {DC = cdc (SP)} \COMMENT{ create a derived component } \RETURN $DC$ @@ -800,7 +808,7 @@ $$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$ \end{algorithmic} \end{algorithm} -The symptom abstraction process allows us to take a functional group of components, +The symptom abstraction process allows us to take a {\fg} 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 @@ -910,13 +918,13 @@ This function also ensures completeness in the model. It ensures that %for all failure modes in the {\fg} are considered in a test~case. % -\ifthenelse {\boolean{paper}} -{ -%% perhaps ref a paper here XXXXX -} -{ -Components with a unitary state property are discussed in chapter \ref{sec:unitarystate}. -} +% \ifthenelse {\boolean{paper}} +% { +% %% perhaps ref a paper here XXXXX +% } +% { +% Components with a unitary state property are discussed in chapter \ref{sec:unitarystate}. +% } %% %% Algorithm 2 %% @@ -1019,8 +1027,9 @@ Components with a unitary state property are discussed in chapter \ref{sec:unita \end{algorithm} Algorithm \ref{alg22} has taken the set of failure modes $ F=fm(FG) $ and returned a set of test cases $TC$. -The next stage is to analyse the effect of each test case on the functional group. - +The next stage is to analyse the effect of each test case on the {\fg}. +Double failure mode checking has been included in this algorithm specifically because of the +implied double failure mode implications of European standard EN298~\cite{en298}. @@ -1046,7 +1055,7 @@ $$ atc(TC) = R $$ \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 = Analyse(tc_j) $} \COMMENT {this is Failure Mode Effects Analysis applied in the context of the {\fg}} %\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} \ENDFOR @@ -1057,7 +1066,7 @@ $$ atc(TC) = R $$ \end{algorithmic} \end{algorithm} -Algorithm \ref{alg33} has built the set $R$, the sub-system/functional group results for each test case. +Algorithm \ref{alg33} has built the set $R$, the sub-system/{\fg} results for each test case. The analysis is primarily a human activity. @@ -1086,7 +1095,7 @@ the {\fg}, not the components failure modes. % Thus we will have a set of results corresponding to our test cases. These share a common index value ($j$ in the algorithm description). -These results are the failure modes of the functional group. +These results are the failure modes of the {\fg}. %Once a functional group has been analysed, it can be re-used in %any other design that uses it. @@ -1106,7 +1115,7 @@ These results are the failure modes of the functional group. This stage collects results into `symptom' sets. Each result from the preceding stage is examined and collected into common symptom sets. -That is to say, each result in a symptom set, from the perspective of the functional group, +That is to say, each result in a symptom set, from the perspective of the {\fg}, has the same failure symptom. Let set $\mathcal{SP}$ be the set of all symptoms, and $\mathcal{R}$ be the set of all test case results. @@ -1198,7 +1207,7 @@ set enforces the `unitary state failure mode constraint' for derived components. %% This final stage, is the creation of the derived component. This derived component may now be used to build -new functional groups at higher levels of fault abstraction. +new {\fgs} at higher levels of fault abstraction. Let $DC$ be a derived component with its own set of failure~modes. $$ cdc: \mathcal{SP} \rightarrow \mathcal{DC} $$