skicat till jmc for lasning.... sen skicker den till javla lat hundar
This commit is contained in:
Robin Clark
parent
8f42d9ef2b
commit
a47f78cde6
@ -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}.
|
||||
|
||||
|
||||
@ -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.
|
||||
|
||||
@ -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} $$
|
||||
|
||||
Loading…
Reference in New Issue
Block a user