robin/Robin_PHD
1
0
Fork 0
Code Issues Pull Requests Actions Packages Projects Releases Wiki Activity

skicat till jmc for lasning.... sen skicker den till javla lat hundar

Browse Source
This commit is contained in:
Robin Clark 2013-07-23 21:52:48 +01:00
parent 8f42d9ef2b
commit a47f78cde6
3 changed files with 306 additions and 297 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
submission_thesis/CH4_FMMD/copy.tex
View File

@ -1163,7 +1163,7 @@ to which we are approving/analysing a system.
%% FIDDLINGING STEREO SUB_SYSTEM EXAMPLE, THE FIDDLINGING CHILDRENS SECTION %% FIDDLINGING STEREO SUB_SYSTEM EXAMPLE, THE FIDDLINGING CHILDRENS SECTION
\subsection{Definition of terms: sound system example.} \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'. %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}. %These are listed in table~\ref{tab:symexdef}.

2
submission_thesis/CH8_Conclusion/copy.tex
View File

@ -555,7 +555,7 @@ leak of radioactive material into the environment.
% %
For the objective failure mode determined by For the objective failure mode determined by
FMEA, that of leakage of coolant, 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 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. would have reacted, and deficiencies in the HMI were not a factor in the failure analysis.

599
submission_thesis/appendixes/algorithmic.tex
View File

@ -239,9 +239,9 @@ an algorithmic context.
\glossary{name={system}, description={A product designed to work as a coherent entity}} \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={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={{\dc}}, 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={{\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 functional group (of components), caused by a combination of its component failure modes}} \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={base component}, description={Any bought in component, or lowest level module/or part}}
%\glossary{name={entry name}, description={entry description}} %\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. % with its own set of failure modes.
This process allows us to modularise and simply FMEA analysis of systems. 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 As a {\fg} is a set of components, the failure~modes
that we have to consider are the failure modes of its components. that we have to consider are the failure modes of its components.
%, as %, 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, 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. 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.} \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. 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. %Single component failures (or combinations) within the functional~group may cause unique symptoms.
%However, m %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'. 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, output stage, and a failed internal audio amplifier,
will both cause the same failure symptom; $no\_sound$ ! 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} %\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} \begin{enumerate}
\item Choose a set of components to form a functional group. \item Choose a set of components to form a {\fg}.
% \item Obtain the list of components in the functional group % \item Obtain the list of components in the functional group
\item Collect the failure modes of each component into a flat set. \item Collect the failure modes of each component into a flat set.
\item Choose all single instances (and optional selected combinations\footnote{ \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 Where simultaneous failures are examined use overlapping contours
% \item For each region on the diagram, make a test case % \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, \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. 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. 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. \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}} \subsection{Single FMMD stage described as a `symptom~abstraction~process'}
{
\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$} 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.
Let the set of all possible components be $\mathcal{C}$ These derived failure mode, failure modes of the {\fg} considered as an entity or component, are abstract
and let the set of all possible failure modes be $\mathcal{F}$. or at a higher level in the systems modular hierarchy.
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.
}
{
%To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}. %To re-cap from the formal FMMD description chapter \ref{chap:fmmdset}.
The FMMD process is now described introducing The FMMD process is now described introducing
set theoretical definitions % formal definitions set theoretical definitions % formal definitions
@ -693,7 +701,7 @@ We can define a function $fm$
%$$ fm ( C ) = F $$ %$$ fm ( C ) = F $$
We overload the notation for the function $fm$ 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} \begin{equation}
fm : FG \rightarrow \mathcal{F} 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: is the set of all derived components, we can define the symptom abstraction process thus:
$$ $$
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent %\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent
@ -722,7 +730,7 @@ this section
%describes the symptom abstraction process %describes the symptom abstraction process
using set theory and procedural descriptions. 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$. and a new derived~component/sub-system $DC$.
%The sub-system $SS$ is a collection %The sub-system $SS$ is a collection
%of failure~modes of the sub-system. %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. % as a component with a known set of failure modes.
\paragraph{Enumerating abstraction levels} \paragraph{Enumerating abstraction levels.}
\label{sec:abstractionlevel} \label{sec:abstractionlevel}
As described in section~\ref{sec:alpha} we can assign an attribute of abstraction level $\abslev$ to 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$). 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$, If we apply the symptom abstraction process $\derivec$,
the resulting derived~component will have an $\abslev$ value the resulting derived~component will have an $\abslev$ value
one higher that the highest $\abslev$ value of any of the components 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 Thus a derived component sourced from base components
will have an $\abslev$ value of 1. 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 %With a derived component $DC$ having an abstraction level
The attribute $\abslev$ can be used to track the The attribute $\abslev$ can be used to track the
level of fault abstraction of components in an FMMD hierarchy. Because base and derived components 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. naturally formed with the abstraction levels increasing with each tier.
\fmmdgloss \fmmdgloss
@ -785,14 +793,14 @@ $$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$
\begin{algorithm}[h+] \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] \begin{algorithmic}[1]
\STATE {F = fm (FG)} \COMMENT{ collect all component failure modes }%from the from the components in the functional~group } \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 {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 }%, for failure mode behaviour of 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 }%of failure for 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 } \STATE {DC = cdc (SP)} \COMMENT{ create a derived component }
\RETURN $DC$ \RETURN $DC$
@ -800,7 +808,7 @@ $$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$
\end{algorithmic} \end{algorithmic}
\end{algorithm} \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 analyse the failure
mode behaviour and create a new entity, a derived~component, that has its own set of failure modes. 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 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 It ensures that %for
all failure modes in the {\fg} are considered in a test~case. all failure modes in the {\fg} are considered in a test~case.
% %
\ifthenelse {\boolean{paper}} % \ifthenelse {\boolean{paper}}
{ % {
%% perhaps ref a paper here XXXXX % %% perhaps ref a paper here XXXXX
} % }
{ % {
Components with a unitary state property are discussed in chapter \ref{sec:unitarystate}. % Components with a unitary state property are discussed in chapter \ref{sec:unitarystate}.
} % }
%% %%
%% Algorithm 2 %% Algorithm 2
%% %%
@ -1019,8 +1027,9 @@ Components with a unitary state property are discussed in chapter \ref{sec:unita
\end{algorithm} \end{algorithm}
Algorithm \ref{alg22} has taken the set of failure modes $ F=fm(FG) $ and returned a set of test cases $TC$. 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$} \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 { $tc_j \in TC$ }
\FORALL { Environmental and Specific Applied States } \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 { $ 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} \STATE{ $ R := R \cup rc_j $ } \COMMENT{Add $rc_j$ to the set R}
\ENDFOR \ENDFOR
@ -1057,7 +1066,7 @@ $$ atc(TC) = R $$
\end{algorithmic} \end{algorithmic}
\end{algorithm} \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. 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 Thus we will have a set of
results corresponding to our test cases. These share a common index value ($j$ in the algorithm description). 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 %Once a functional group has been analysed, it can be re-used in
%any other design that uses it. %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. This stage collects results into `symptom' sets.
Each result from the preceding stage is examined and collected Each result from the preceding stage is examined and collected
into common symptom sets. 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. has the same failure symptom.
Let set $\mathcal{SP}$ be the set of all symptoms, Let set $\mathcal{SP}$ be the set of all symptoms,
and $\mathcal{R}$ be the set of all test case results. 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 final stage, is the creation of the derived component.
This derived component may now be used to build 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. Let $DC$ be a derived component with its own set of failure~modes.
$$ cdc: \mathcal{SP} \rightarrow \mathcal{DC} $$ $$ cdc: \mathcal{SP} \rightarrow \mathcal{DC} $$