741 lines
31 KiB
TeX
741 lines
31 KiB
TeX
|
|
\chapter{Algorithmic Description of FMMD}
|
|
%\label{sec:symptom_abstraction}
|
|
\label{sec:algorithmfmmd}
|
|
|
|
This chapter defines the process for performing one stage of the FMMD process i.e.
|
|
from forming a {\fg} to creating a {\dc}.
|
|
%
|
|
The FMMD process is then examined in greater %levels of
|
|
detail and described with set theory in
|
|
an algorithmic context.
|
|
%
|
|
The intention for defining FMMD in algorithmic and set theoretic terms, is to provide
|
|
a solid specification for the process that could guide a software implementation.% for it.
|
|
|
|
|
|
\fmodegloss
|
|
|
|
\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={{\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}}
|
|
|
|
|
|
|
|
\nocite{safeware}
|
|
\section{Overview of the FMMD analysis Process}
|
|
The FMMD process is described in chapter~\ref{sec:chap4},
|
|
to re-cap, FMMD has four main stages:
|
|
\begin{itemize}
|
|
\item collection of components to form {\fgs},
|
|
\item applying FMEA to the {\fg},
|
|
\item collecting common symptoms from the FMEA results,
|
|
\item creating a {\dc} representing the failure mode behaviour of the {\fg}.
|
|
\end{itemize}
|
|
%
|
|
%This is termed `symptom~abstraction'.
|
|
% TO DO: separate these two:
|
|
%
|
|
% \paragraph{FMMD analysis Objective.}
|
|
% The objective of `symptom abstraction' is to analyse the functional~group and find
|
|
% how it can fail
|
|
% when specified components within it fail.
|
|
% Once we know how a functional~group can fail, we can treat it as a component or sub-system
|
|
% with its own set of failure modes.
|
|
% Once the failure symptoms for a {\fg} are known, the {\fg} can be treated as a component or sub-system
|
|
% with its own set of failure modes.
|
|
This process allows us to modularise and thus simplify FMEA analysis of systems.
|
|
%
|
|
%We later add another step to this process, that of defining the combinations of {\fms} considered for each FMEA
|
|
%scenario.
|
|
%The FMMD process stages are expanded upon
|
|
%below.
|
|
|
|
|
|
\paragraph{FMEA applied to the {\fg}: choosing `test~cases'.}
|
|
As a {\fg} is a collection of components, the failure~modes
|
|
that we have to consider are the failure modes of its components.
|
|
%, as
|
|
%developed in the function definition $fm : \;\mathcal{G} \rightarrow \mathcal{F}$.
|
|
%The aim here is to build `test cases',
|
|
Single or combinations of failure~modes are used to create failure~mode analysis scenarios, or test cases.
|
|
%Each failure mode (or combination of) investigated is termed a `test case'.
|
|
%Each `test case' is analysed.
|
|
%
|
|
The component failure modes in each test case
|
|
are examined with respect to their effect on the {\fg}
|
|
(in contrast, traditional FMEA examines each component failure modes effect on a whole system).
|
|
%
|
|
The aim of FMMD analysis is to find out how the {\fg} fails given
|
|
each test case.
|
|
%
|
|
%The goal of the process is to produce a set of failure modes from the perspective of the user of the {\fg}.
|
|
%
|
|
%In other words, if a designer has a previously analysed module to use, he/she need not be concerned with
|
|
%the failure modes of its components: it is handled 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 (i.e. as a {\dc}).
|
|
|
|
\paragraph{Environmental Conditions or Operational States.}
|
|
%
|
|
Each test case must also be considered for all %applied/
|
|
operational states and
|
|
%in the for the case of each applied states or
|
|
environmental conditions to which it may be exposed. In this way, all possible
|
|
failure mode behaviour due to all the conditions that can be applied for a test case will be examined.
|
|
%
|
|
\paragraph{Symptom Identification.}
|
|
When all `test~cases' have been analysed, we have a set of FMEA results. % applied.
|
|
These results can be viewed as symptoms of failure of the {\fg}.
|
|
%
|
|
%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 {\fg}, will have the same symptoms.
|
|
%These can be collected as `common symptoms'.
|
|
%
|
|
%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$ !
|
|
|
|
|
|
|
|
|
|
\paragraph{Collection of Symptoms.}
|
|
%Looking at the
|
|
% examining failure from the
|
|
% functional group perspective failure modes, we collect
|
|
% some of these into common `symptoms' where possible.
|
|
% %
|
|
% Some test cases may cause
|
|
% unique failure modes at the functional group level. These can be termed
|
|
% lone symptoms.
|
|
% %
|
|
% The common symptoms of failure and lone~symptoms are identified and collected.
|
|
% %
|
|
% We can now create a new component and consider the symptoms as its failure modes.
|
|
Common symptoms of failure of the {\fg} are collected.
|
|
%
|
|
We can now create a new component to represent the {\fg} and consider these aggregated symptoms as its failure modes.
|
|
%
|
|
We call this new component a `{\dc}'.
|
|
%
|
|
%Note that here, b
|
|
Because the FMMD process is bottom up, we can ensure that all failure modes
|
|
from the components in a {\fg} have been considered.
|
|
%\footnote{Software can check that all failure modes have been included in at least one test case, and modelled individually. For Double
|
|
%Simultaneous fault mode checking, all valid double failure modes can be checked for coverage as well.}.
|
|
%
|
|
Were failure~modes to be missed, the resulting failure mode model would be %dangerously
|
|
incomplete.
|
|
%
|
|
It is possible here for an automated system to flag un-handled failure modes.
|
|
%which solves the main failing of top~down methodologies
|
|
%\cite{topdownmiss},
|
|
%that of not
|
|
%guaranteeing to model all component failure modes.
|
|
%\ref{requirement at the start}
|
|
|
|
|
|
\section{A single stage of the FMMD process}
|
|
|
|
%\paragraph{To analyse a base level Derived~Component/sub-system}
|
|
|
|
The expanded FMMD process can now be described in five steps:
|
|
|
|
\begin{enumerate}
|
|
\item Choose a set of components to form a {\fg}, and collect the failure modes of each component in the {\fg} into a flat set. %% COLLECT FAILURE MODES
|
|
\item Choose all single instances (and optional selected combinations\footnote{ %% DETERMINE TEST CASES
|
|
Some specific combinations of failure modes might be included. For instance where
|
|
a very reliable part is duplicated but very critical, like the 4 engines on a 747
|
|
aircraft.}) of the failure modes to
|
|
form `test~cases'.
|
|
% \item If required, create test cases from all valid double failure mode combinations within the {\fg}.
|
|
% \item Draw these as contours on a diagram
|
|
% \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, %% APPLY FMEA
|
|
we determine the failure~mode behaviour of the {\fg}.
|
|
%
|
|
This is a human process, applying FMEA for each test case.
|
|
%
|
|
Where specific environmental conditions, or operational states are germane to the {\fg}, these must also be examined
|
|
for each test case.
|
|
%
|
|
\item Collect common~symptoms by determining which test cases produce the same fault symptoms {\em from the perspective of the {\fg}}. %% COLLECT COMMON SYMPTOMS
|
|
%
|
|
\item The common~symptoms are now the fault mode behaviour of the {\fg}. %% CREATE DC
|
|
i.e. given the {\fg} as a `black box' the symptoms are the ways in which it can fail.
|
|
%
|
|
A new `{\dc}' can now be created where each common~symptom, or lone symptom, is a failure~mode of this new component.
|
|
\end{enumerate}
|
|
|
|
|
|
|
|
|
|
\subsection{Single stage of FMMD described as a `symptom~abstraction~process'}
|
|
|
|
|
|
A single stage of FMMD analysis can be described as symptom abstraction.
|
|
%
|
|
This is because the failure modes of a {\dc} are at a higher---or meta/more~abstract level---than the
|
|
component failure modes it was derived from.
|
|
%we take a {\fg} and from its component failure modes and FMEA analysis, derive symptom of failure. %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
|
|
that will be used in the algorithmic description of FMMD.
|
|
%below.
|
|
%
|
|
Let the set of all possible components be $\mathcal{C}$
|
|
and let the set of all possible failure modes be $\mathcal{F}$ and $\mathcal{P}$ the powerset.
|
|
|
|
We can define a function $fm$ which returns the failure modes for a given component (see section~\ref{sec:formal7}):
|
|
|
|
\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 $$
|
|
|
|
We overload the notation for the function $fm$
|
|
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} .
|
|
\end{equation}
|
|
|
|
|
|
|
|
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
|
|
\derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
|
|
$$
|
|
|
|
%The next section describes the details of the symptom abstraction process.
|
|
|
|
}
|
|
|
|
|
|
|
|
%\section{A Formal Algorithmic Description of `Symptom Abstraction'}
|
|
\section{Algorithmic Description}
|
|
\label{sec:symptomabs}
|
|
The algorithm for {\em symptom abstraction} is described in
|
|
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 {\fg} $FG$
|
|
%and a new derived~component/sub-system $DC$.
|
|
%The sub-system $SS$ is a collection
|
|
%of failure~modes of the sub-system.
|
|
% Note that
|
|
% $DC$ is a derived component at a higher level of fault analysis abstraction
|
|
% than the functional~group from which it was derived.
|
|
% %Thus, ke
|
|
% $DC$ can now be treated
|
|
% as a component with a known set of failure modes.
|
|
%\FORALL { $c \in FG $ } \COMMENT{Find the highest abstraction level of any component in the functional group}
|
|
% \IF{$c.\abslev > \abslev_{max}$}
|
|
% $\abslev_{max} = c.\abslev$
|
|
% \ENDIF
|
|
%\STATE { $ FM(c) \in FG_{cfm} $ } \COMMENT {Collect all failure modes from each component into the set $FM_{cfm}$}
|
|
%\ENDFOR
|
|
%
|
|
By defining the process and describing it using set theory, constraints and
|
|
verification checks %in the process
|
|
can be stated formally.
|
|
%
|
|
The algorithm, represented by the symbol `$\derivec$', is described using five algorithmic steps below.
|
|
%These are described using the Algorithm environment in the next section \ref{algorithms}.
|
|
%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
|
|
|
\section{Algorithmic Description of Symptom Abstraction}
|
|
%\clearpage
|
|
$$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} $$
|
|
|
|
\begin{algorithm}[h+]
|
|
|
|
\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 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$
|
|
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
The symptom abstraction process allows us to take a {\fg} of components,
|
|
analyse the failure
|
|
mode behaviour and create a new entity, a {\dc} that has its own set of failure modes.
|
|
The checks and constraints applied in the algorithm ensure that all component failure
|
|
modes are covered.
|
|
This process provides the analysis `step' to building a hierarchical failure mode model
|
|
from the bottom-up.
|
|
|
|
|
|
|
|
|
|
|
|
%\clearpage
|
|
\subsection{ Determine Failure Modes to Examine}
|
|
|
|
The first stage is to find the failure modes to consider for
|
|
analysis,
|
|
using the earlier definition of the function $fm$.
|
|
%
|
|
The function $fm$ applied to a component returns the failure modes for that component.
|
|
Thus its domain is the set of all components $\mathcal{C}$ and its range
|
|
is the powerset of all failure modes $\mathcal{P}\,\mathcal{F}$.
|
|
%
|
|
$$ fm : \mathcal{C} \rightarrow \mathcal{P}\,\mathcal{F} $$
|
|
%
|
|
A {\fg} is a collection of components $G$ such that $\mathcal{G} \in \mathcal{P}\,\mathcal{C}$.
|
|
%
|
|
The function $fm$ can be overloaded with a {\fg} $\mathcal{G}$ as its domain
|
|
and the power-set of all failure modes as its range.
|
|
%
|
|
%
|
|
$$ fm: \mathcal{G} \rightarrow \mathcal{P}\,\mathcal{F} $$
|
|
%
|
|
%
|
|
%
|
|
The next task is to formulate `test~cases'. These are a collection of combinations of these {\fms} and will be used
|
|
in the analysis stages.
|
|
|
|
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%\clearpage
|
|
\subsection{ Determine Test Cases}
|
|
|
|
From the failure modes associated with the functional~group,
|
|
we now need to determine test cases.
|
|
The test cases are collections of failure modes.
|
|
These can be formed from single failure modes or failure modes in combination.
|
|
Let $\mathcal{TC}$ be the set of all test cases, $\mathcal{F}$
|
|
be the set of all failure modes.
|
|
%(associated with the functional group $FG$).
|
|
We define the function $dtc$ thus:
|
|
%
|
|
$$ dtc: \mathcal{F} \rightarrow \mathcal{TC}, $$
|
|
%
|
|
given by
|
|
%
|
|
$$ dtc(F) = TC. $$
|
|
%
|
|
In algorithm \ref{alg22}, the function \textbf{chosen} means that
|
|
the failure modes for a particular test case have been chosen by
|
|
a human operator and are additional to those chosen by the automated process (i.e they are
|
|
special case test cases involving multiple failure modes).
|
|
The function \textbf{unitary state} means that all test
|
|
cases can have no pairs of failure modes sourced from the same component, see section~\ref{sec:unitarystate}.
|
|
%
|
|
\label{sec:completetest}
|
|
%
|
|
The $dtc$ function enforces completeness in the model
|
|
by ensuring that %for
|
|
all failure modes in components in the {\fg} are included in at least one test~case.
|
|
%
|
|
%
|
|
%%
|
|
%
|
|
\begin{algorithm}[h+]
|
|
~\label{alg2}
|
|
\caption{Determine Test Cases: dtc: (F) } \label{alg22}
|
|
\begin{algorithmic}[1]
|
|
|
|
\REQUIRE {F is a non empty flat set of failure modes }
|
|
|
|
\STATE { All test cases are chosen by the investigating engineer(s). Typically all single
|
|
component failures are investigated
|
|
with some specially selected combination faults}
|
|
|
|
\STATE { Let $TC$ be the set of test cases }
|
|
\STATE { Let $tc_j$ be set of component failure modes where $j$ is an index of $J$}
|
|
\COMMENT { Each set $tc_j$ is a `test case' }
|
|
%\STATE { $ \forall j \in J | tc_j \in TC $ } \COMMENT {Ensure the test cases are complete and unique}
|
|
|
|
\STATE { $ TC := \emptyset $ } \COMMENT{Initialise set of test cases}
|
|
\STATE { $ j := 1 $ } \COMMENT{Initialise index of test cases}
|
|
|
|
\FORALL { $ f \in F $ }
|
|
\STATE{$ tc_j := f $} \COMMENT{ Assign one test case per single fault mode }
|
|
\STATE{ $ j := j + 1 $}
|
|
\ENDFOR
|
|
|
|
%\STATE { Let $ptc$ be a provisional test case } \COMMENT{ Determine Test cases with simultaneous failure modes }
|
|
|
|
\IF{DoubleFaultChecking}
|
|
|
|
%\STATE { Let $ptc$ be a provisional test case }
|
|
\FORALL { $ f1,f2 \in F $ }
|
|
\STATE { $ ptc := \{ f1,f2 \} $ } \COMMENT{Make $ptc$ a provisional test case}
|
|
%\STATE { FINDING ERRORS IN LATEX SOURCE IS FUCKING ANNOYING}
|
|
% ESCPECIALLY IN THIS FUCKING ENVIRONMENT 22OCT2010
|
|
%% OK maybe you can't have comments after IF: half an hour wasted...
|
|
\IF { $ {isunitarystate}(ptc) $ } % \COMMENT{Ensure the chosen failure mode set is unitary state compliant}
|
|
\STATE{ $ j := j + 1 $} % latex bug hunt game what fun ! #2
|
|
\STATE { $ tc_j := ptc $}
|
|
\STATE { $ TC := TC \cup tc_j $ }
|
|
\ENDIF
|
|
\ENDFOR
|
|
\ENDIF
|
|
|
|
\FORALL { $ ptc \in \mathcal{P}(F) $ } %%\mathcal{P} F $ }
|
|
%%\STATE { $ ptc \in \mathcal{P} F $ } \COMMENT{Make a provisional test case}
|
|
\IF { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {isunitarystate}(ptc)$ } %%% \COMMENT{IF this combination of faults is chosen as an additional Test case include it in TC}
|
|
\STATE{ $ j := j + 1 $} % latex bug hunt game #1
|
|
\STATE { $ tc_j := ptc $}
|
|
\STATE { $ TC := TC \cup tc_j $ }
|
|
\ENDIF
|
|
\ENDFOR
|
|
|
|
%\FORALL { $tc_j \in TC$ }
|
|
%\ENSURE {$ tc_j \in \bigcap FG_{cfm} $}
|
|
%
|
|
% Lone commoents like the one below causing incredibly annoying very difficult to trace errors: cunt
|
|
%\COMMENT { require that the test case is a member of the powerset of $F$ }
|
|
%\ENSURE { $ \forall \; j2 \; \in J ( \forall \; j1 \; \in J | tc_{j1} \neq tc_{j2} \; \wedge \; j1 \neq j2 ) $}
|
|
%\COMMENT { Test cases must be unique }
|
|
%\ENDFOR
|
|
%
|
|
% \IF{Single fault checking}
|
|
% \STATE { let $f$ represent a component failure mode }
|
|
% %\ENSURE { That all failure modes are represented in at least one test case }
|
|
% \ENSURE { $ \forall f \;such\;that\; (f \in F)) \wedge (f \in \bigcup TC) $ }
|
|
% \COMMENT { This corresponds to checking that at least each failure mode is considered at
|
|
% least once in the analysis; more rigorous cardinality constraint
|
|
% checks may be required for some safety standards}
|
|
% \ENDIF
|
|
%
|
|
% \IF{Double fault checking}
|
|
% \STATE { let $f1,f2$ represent component failure modes, and $c$ any component in the functional group }
|
|
% %\ENSURE { That all failure modes are represented in at least one test case }
|
|
% \ENSURE { $ \forall f1,f2 \;where\; (f1,f2) \not\in c\;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) $ }
|
|
% \COMMENT { This corresponds to checking that each possible double failure mode is considered
|
|
% as a test case; more rigorous cardinality constraint
|
|
% checks may be required for some safety standards. Note if both failure modes
|
|
% in the check are sourced from the same component $c$, the test case is impossible
|
|
% under unitary state failure mode conditions}
|
|
% \ENDIF
|
|
%
|
|
\ENSURE { $ \forall j1,j2 \in J \; such\; that\; j1 \neq j2 \big( tc_{j1} \neq tc_{j2} \big) $}
|
|
\ENSURE { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ }
|
|
\RETURN $TC$
|
|
% some european standards
|
|
% imply checking all double fault combinations\cite{en298} }
|
|
|
|
%\hline
|
|
|
|
\end{algorithmic}
|
|
\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 {\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}.
|
|
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
\clearpage
|
|
\subsection{ Analyse Test Cases}
|
|
%%
|
|
%% Algorithm 3
|
|
%%
|
|
The test cases are now analysed for their impact on the behaviour of the functional~group.
|
|
Let $\mathcal{R}$ be the set of all test case analysis results, indexed by $j$ (the same index used to identify the test cases $tc_{j}$).
|
|
The function $atc$ is defined thus:
|
|
$$ atc: \mathcal{TC} \rightarrow \mathcal{R} , $$
|
|
given by
|
|
$$ atc(TC) = R .$$
|
|
|
|
\begin{algorithm}[h+]
|
|
~\label{alg3}
|
|
\caption{Analyse Test Cases: atc(TC) } \label{alg33}
|
|
\begin{algorithmic}[1]
|
|
\STATE { let r be a `test case result'}
|
|
\STATE { Let the function $Analyse : tc \rightarrow r $ } \COMMENT { This analysis is a human activity, examining the component failure~modes in the test case and determining how the functional~group will fail under those conditions}
|
|
\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 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
|
|
\ENDFOR
|
|
\RETURN $R$
|
|
|
|
%\hline
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
|
|
Algorithm \ref{alg33} has built the set $R$, the sub-system/{\fg} results for each test case.
|
|
|
|
|
|
The analysis is primarily a human activity.
|
|
%
|
|
%Each test case is examined in detail.
|
|
%
|
|
%
|
|
Calculations or simulations
|
|
are performed to determine how the failure modes in each test case will
|
|
affect the functional~group.
|
|
Ideally field data and/or formal physical testing should be used in addition to static failure mode reasoning
|
|
where possible.
|
|
%
|
|
When all the test cases have been analysed,
|
|
we will have a `result' for each `test case'.
|
|
%
|
|
Each result will be described from the perspective of %{\wrt} to
|
|
the {\fg}, not the components failure modes.
|
|
%in its test case.
|
|
%
|
|
%In the case of a simple
|
|
%electronic circuit, we could calculate the effect on voltages
|
|
%within the circuit given a certain component failure mode, for instance.
|
|
%%
|
|
|
|
%
|
|
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 {\fg}.
|
|
|
|
%Once a functional group has been analysed, it can be re-used in
|
|
%any other design that uses it.
|
|
%Often safety critical designs have repeated sections (such as safety critical digital inputs or $4\rightarrow20mA$
|
|
%inputs), and in this case the analysis would only need to be performed once.
|
|
%
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%\clearpage
|
|
\subsection{ Find Common Symptoms}
|
|
%%
|
|
%% Algorithm 4
|
|
%%
|
|
%This stage analyses the results from bottom-up FMEA analysis ($R$), and collects
|
|
%results that, from the perspective of the functional~group, have the same failure symptom.
|
|
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 {\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.
|
|
%
|
|
We define the function $fcs$ thus:
|
|
%
|
|
$$fcs: \mathcal{R} \rightarrow \mathcal{SP} ,$$
|
|
given by
|
|
$$ fcs(R) = SP .$$
|
|
%
|
|
%\begin{algorithm}[h+]
|
|
% ~\label{alg4}
|
|
%
|
|
%\caption{Find Common Symptoms: fcs($R$)} \label{alg44}
|
|
%
|
|
%\begin{algorithmic}[1]
|
|
%
|
|
%
|
|
% %\REQUIRE {All failure modes for the components in $fm_i = fm(fg_i)$}
|
|
% \STATE {Let $sp_l$ be a set of `test cases results' where $l$ is an index set $L$}
|
|
% \STATE {Let $SP$ be a set whose members are the indexed `symptoms' $sp_l$}
|
|
% \COMMENT{ $SP$ is the set of `fault symptoms' for the sub-system}
|
|
% \STATE{$SP := 0$} \COMMENT{ initialise the `symptom family set'}
|
|
%%
|
|
% %\COMMENT{This corresponds to a fault symptom of the functional group $FG$}
|
|
% %\COMMENT{where double failure modes are required the cardinality constrained powerset of two must be applied to each failure mode}
|
|
%\REPEAT
|
|
%
|
|
% \STATE{$sp_l := 0$} \COMMENT{ initialise the `symptom'}
|
|
% \STATE{$Let \; sp_l \in \mathcal{P} R$ such that R is in a common symptom group } \COMMENT{determine common symptoms from the results set}
|
|
% \STATE{$ R := R \backslash sp_l $} \COMMENT{remove the results used from the results set}
|
|
% \STATE{$ SP := SP \cup sp_l$} \COMMENT{collect the symptom into the symtom family set SP}
|
|
% \STATE{$ l := l + 1 $} \COMMENT{move the index up for the next symptom to collect}
|
|
%
|
|
%\UNTIL{ $ R = \emptyset $ } \COMMENT{continue until all results belong to a symptom}
|
|
%
|
|
%%% \FORALL { $ r_j \in R$ }
|
|
%%% \STATE { $sp_l \in \mathcal{P} R \wedge sp_l \in SP$ }
|
|
%%% %\STATE { $sp_l \in \bigcap R \wedge sp_l \in SP$ }
|
|
%%% \COMMENT{ Collect common symptoms.
|
|
%%% Analyse the sub-system's fault behaviour under the failure modes in $tc_j$ and determine the symptoms $sp_l$ that it
|
|
%%%causes in the functional group $FG$}
|
|
%%% %\ENSURE { $ \forall l2 \in L ( \forall l1 \in L | \exists a \in sp_{l1} \neq \exists b \in sp_{l2} \wedge l1 \neq l2 ) $}
|
|
%%%
|
|
%%% \ENSURE {$ \forall a \in sp_l \;such\;that\; \forall sp_i \in \bigcap_{i=1..L} SP ( sp_i = sp_l \implies a \in sp_i)$}
|
|
%%% \COMMENT { Ensure that the elements in each $sp_l$ are not present in any other $sp_l$ set }
|
|
%%%
|
|
%%% \ENDFOR
|
|
% \STATE { The Set $SP$ can now be considered to be the set of fault modes for the sub-system that $FG$ represents}
|
|
%
|
|
% \RETURN $SP$
|
|
%%\hline
|
|
%
|
|
%\end{algorithmic}
|
|
%\end{algorithm}
|
|
%
|
|
%Algorithm \ref{alg44}
|
|
This raises the failure~mode abstraction level, $\abslev$ (see section~\ref{sec:alpha}).
|
|
The failures have now been considered not from the component level, but from the sub-system or
|
|
functional~group level.
|
|
We now have a set $SP$ of the symptoms of failure.
|
|
%
|
|
\ifthenelse {\boolean{paper}}
|
|
{
|
|
Component failure modes must be mutually exclusive.
|
|
That is to say only one specific failure mode may be active at any time.
|
|
This condition/property has been termed unitary state failure mode.
|
|
Ensuring that no result belongs to more than
|
|
one symptom set, enforces this, for the derived
|
|
component created in the next stage.
|
|
}
|
|
{
|
|
Ensuring that no result belongs to more than one symptom
|
|
set enforces the `unitary state failure mode constraint' for derived components (see section~\ref{sec:unitarystate}).
|
|
}
|
|
|
|
%% Interesting to draw a graph here.
|
|
%% starting with components, branching out to failure modes, then those being combined to
|
|
%% test cases, the test cases producing results, and then the results collected into
|
|
%% symptoms.
|
|
%% the new component then gets the symptoms as failure modes.
|
|
%% must be drawn !!!!!
|
|
%% 04AUG2010 ~~~~ A27 refugee !!!
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
%\clearpage
|
|
\subsection{ Create Derived Component}
|
|
%%
|
|
%% Algorithm 5
|
|
%%
|
|
This final stage is the creation of the derived component.
|
|
This derived component may now be used to build
|
|
new {\fgs} at higher levels of fault abstraction.
|
|
Let $DC$ be a derived component with its own set of failure~modes.
|
|
We define the function $cdc$ thus:
|
|
$$ cdc: \mathcal{SP} \rightarrow \mathcal{DC} , $$
|
|
|
|
given by
|
|
|
|
$$ cdc(SP) = DC . $$
|
|
|
|
The new component will have a set of failure modes that correspond to the common symptoms collected from the $FG$.
|
|
|
|
%\begin{algorithm}[h+]
|
|
% ~\label{alg5}
|
|
%
|
|
%\caption{Create Derived Component: cdc(SP) } \label{alg55}
|
|
%
|
|
%\begin{algorithmic}[1]
|
|
%
|
|
% \STATE { Let $DC$ be a derived component with failure modes $f$ indexed by $l$ }
|
|
% \FORALL { $sp_l \in SP$ }
|
|
% \STATE { $ f_l = ConvertToFaultMode(sp_l) $}
|
|
% %\STATE { $ f_l \in DC $} \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
|
|
% \STATE { $DC := DC \cup f_l$ } \COMMENT{ this is saying place $f_l$ into $DC$'s collection of failure modes}
|
|
%
|
|
% \ENDFOR
|
|
% \ENSURE { $fm(DC) \neq \emptyset$ } \COMMENT{Ensure that DC has a known set of failure modes}
|
|
% \RETURN DC
|
|
%%\hline
|
|
%
|
|
%\end{algorithmic}
|
|
%\end{algorithm}
|
|
|
|
%Algorithm \ref{alg55}
|
|
The function $cdc$ is the final stage in the process. We now have a
|
|
derived~component $DC$, which has its own set of failure~modes. This can now be
|
|
used in with other components (or derived~components)
|
|
to form functional~groups at higher levels of failure~mode~abstraction.
|
|
%Hierarchies of fault abstraction can be built that can model an entire SYSTEM.
|
|
\paragraph{Enumerating abstraction levels.}
|
|
\label{sec:abstractionlevel}
|
|
As described in section~\ref{sec:alpha} we can assign the attribute of abstraction level $\abslev$ to
|
|
components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$).
|
|
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 than the highest $\abslev$ value of any of the components
|
|
in the {\fg} used to derive it.
|
|
%
|
|
Thus a derived component sourced from base components
|
|
will have an $\abslev$ value of 1.
|
|
%
|
|
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 {\fgs}, a hierarchy is
|
|
naturally formed with the abstraction levels increasing with each tier.
|
|
%
|
|
\fmmdgloss
|
|
|
|
|
|
|
|
|
|
\subsection{Hierarchical Simplification}
|
|
|
|
Because symptom abstraction aggregates fault modes, the number of faults to handle should decrease
|
|
as the hierarchy progresses upwards.
|
|
%This is seen by casual observation of real life Systems. NEED A GOOD REF HERE
|
|
At the highest levels the number of faults
|
|
is significantly less than the sum of its component failure modes.
|
|
A sound system might have, for instance only four faults at its highest or system level,
|
|
\small
|
|
$$ SoundSystemFaults = \{TUNER\_FAULT, CD\_FAULT, SOUND\_OUT\_FAULT, IPOD\_FAULT\}$$
|
|
\normalsize
|
|
The number of causes for any of these faults is very large.
|
|
%
|
|
It does not matter to the user, which combination of component failure~modes caused the fault.
|
|
%
|
|
But as the hierarchy goes up in abstraction level, the number of failure modes goes down for each level:
|
|
as is found in practise in real world systems.
|
|
|
|
\subsection{Traceable Fault Modes}
|
|
|
|
Because the fault modes are determined from the bottom-up, the causes
|
|
for all high level faults naturally form trees.
|
|
%
|
|
That is to say from the bottom-up causes become symptoms, which in the next level become causes as we traverse up the tree.
|
|
%
|
|
This is demonstrated in the examples chapter~\ref{sec:chap5} where DAGS are drawn linking failure mode causes and symptoms
|
|
in FMMD analysis hierarchies.
|
|
%
|
|
These trees can be also traversed to produce
|
|
minimal cut sets\cite{nasafta} or entire FTA trees\cite{nucfta}, and by
|
|
analysing the statistical likelihood of the component failures,
|
|
the Mean Time to Failure (MTTF) and SIL\cite{en61508} levels can be automatically calculated.
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|