765 lines
30 KiB
TeX
765 lines
30 KiB
TeX
|
|
\chapter{Algorithmic Description of FMMD}
|
|
%\label{sec:symptom_abstraction}
|
|
\label{sec:algorithmfmmd}
|
|
|
|
This appendix formalises the process for performing one stage of the FMMD process %i.e.
|
|
from a given {\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.
|
|
|
|
|
|
%\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 {\fgs},
|
|
\item collecting common symptoms from the FMEA results,
|
|
\item creating a {\dc} modelling the failure mode behaviour of the {\fg}.
|
|
\end{itemize}
|
|
%
|
|
\fmmdgloss
|
|
%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
|
|
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 {\fms} or combinations 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}).
|
|
\fmmdgloss
|
|
\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 all the test~cases will be examined.
|
|
%
|
|
\paragraph{Symptom Identification.}
|
|
When all test~cases have been analysed, a set of FMEA results exists for the given {\fg}. % 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.}
|
|
\fmmdgloss
|
|
%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.
|
|
%
|
|
A new component is created to represent the {\fg} and the aggregated symptoms considered as its failure modes.
|
|
%
|
|
This new component is called a `{\dc}'.
|
|
%
|
|
%Note that here, b
|
|
Because the FMMD process is bottom up, it can be ensured 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{Expanding on 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:
|
|
\fmmdgloss
|
|
\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
|
|
the failure~mode behaviour of the {\fg} is determined.
|
|
%
|
|
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'}
|
|
\fmmdglossSA
|
|
|
|
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.
|
|
\fmmdgloss
|
|
The function $fm$ is defined 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 $$
|
|
|
|
The notation for the function $fm$ is overloaded
|
|
and defined for the set of 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, the symptom abstraction process is defined thus:
|
|
$$
|
|
%\derivec : SubSystemComponentFaultModes \rightarrow DerivedComponent
|
|
\derivec : \mathcal{FG} \rightarrow \mathcal{DC} .
|
|
$$
|
|
\fmmdglossSA
|
|
%The next section describes the details of the symptom abstraction process.
|
|
|
|
}
|
|
|
|
|
|
|
|
%\section{A Formal Algorithmic Description of `Symptom Abstraction'}
|
|
|
|
\section{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}.
|
|
%
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
% As a function $\derivec$ has the following signature:
|
|
%
|
|
%
|
|
% %\clearpage
|
|
% $$ \derivec: \mathcal{FG} \rightarrow \mathcal{DC} .$$
|
|
\fmmdglossSA
|
|
\begin{algorithm}
|
|
\caption{Derive new `Component' $DC$ from a given {\fg} $FG$: $\derivec(FG)$}
|
|
\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 }
|
|
|
|
\State \textbf{return} $DC$
|
|
|
|
\end{algorithmic}
|
|
\label{alg66}
|
|
\end{algorithm}
|
|
\fmmdglossSA
|
|
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.
|
|
%
|
|
\fmmdgloss
|
|
|
|
|
|
|
|
|
|
%\clearpage
|
|
\subsection{Determine Failure Modes to Examine}
|
|
\fmodegloss
|
|
The first stage is to find the failure modes to consider for
|
|
analysis,
|
|
using the earlier definition of the function $fm$ applied to
|
|
all components within the given {\fg}.
|
|
%
|
|
% 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,
|
|
test cases must next be determined.
|
|
%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$).
|
|
The function $dtc$ is defined 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 test~cases involving multiple failure modes).
|
|
%
|
|
\fmmdglossMUTEX
|
|
%
|
|
The function \textbf{isunitarystate}
|
|
takes as its argument a test~case
|
|
and returns true if no pairs of that test~case's
|
|
failure modes are sourced from the same component (see section~\ref{sec:unitarystate}).
|
|
%
|
|
In other words, this function tests
|
|
that {\fms} in test~cases
|
|
only use {\fms} that are mutually exclusive within components.
|
|
%
|
|
\label{sec:completetest}
|
|
%
|
|
The $dtc$ function enforces completeness in the model
|
|
by ensuring that %for
|
|
all failure modes of the components in the {\fg} are included in at least one test~case.
|
|
%
|
|
%
|
|
%%
|
|
%
|
|
%{ \footnotesize
|
|
\begin{algorithm}[h+]
|
|
\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 a set of test cases } \Comment {this set is used to collect the test cases}
|
|
\State { Let $tc_j$ be a set of component failure modes where $j$ is an index of $J$}
|
|
\Comment { Each set $tc_j$ is a `test~case' and $TC = \bigcup_{j \in J} \{tc_j\}$ where $J \subset \mathbb{N}_{+}$ }
|
|
|
|
\State { $ TC := \emptyset $ } \Comment{Initialise set of test cases}
|
|
\State { $ j := 1 $ } \Comment{Initialise index of test cases}
|
|
|
|
\ForAll { $ f \in F $ } \Comment{ Assign one test case per single fault mode }
|
|
\State{$ tc_j := f $}
|
|
\State { $ TC := TC \cup tc_j $ } \Comment{ place this test case into the set TC }
|
|
\State{ $ j := j + 1 $}
|
|
\EndFor
|
|
|
|
%\State { Let $ptc$ be a provisional test case } \Comment{ Determine Test cases with simultaneous failure modes }
|
|
|
|
\If{DoubleFaultChecking = TRUE} \Comment{ Assign one test case per valid double fault mode } %\State { Let $ptc$ be a provisional test case }
|
|
\ForAll { $ f_1,f_2 \in F $ }
|
|
\State { $ ptc := \{ f_1,f_2 \} $ } \Comment{Make $ptc$ a provisional test case}
|
|
%\State { FINDING ERRORS IN LATEX SOURCE IS challenging}
|
|
% ESCPECIALLY IN THIS 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 $ } \Comment{ place this test case into the set TC }
|
|
\EndIf
|
|
\EndFor
|
|
\EndIf
|
|
%
|
|
\ForAll { $ ptc \in \mathcal{P}(F) $ } \Comment{for all subsets of F} %%\mathcal{P} F $ }
|
|
% \State { $ ptc \in \mathcal{P} F $ } \Comment{Make $ptc$ a provisional test case}
|
|
\If { ${chosen}(ptc) \wedge ptc \not\in TC \wedge {isunitarystate}(ptc)$ }
|
|
\State{ $ j := j + 1 $} % latex bug hunt game #1
|
|
\State { $ tc_j := ptc $}
|
|
\State { $ TC := TC \cup tc_j $ }
|
|
\EndIf
|
|
\EndFor
|
|
%
|
|
%\algstore
|
|
%\algrestore
|
|
%
|
|
\algstore{myalg}
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
\clearpage
|
|
|
|
%
|
|
%Algorithm~\ref{alg22} continued below.
|
|
%
|
|
\begin{algorithm}
|
|
\begin{algorithmic} [1]
|
|
\algrestore{myalg}
|
|
\Ensure { $ \forall j_1,j_2 \in J \; such\; that\; j_1 \neq j_2 \big( tc_{j_1} \neq tc_{j_2} \big) $} \Comment{Ensure test cases are distinct}
|
|
\Ensure { $ \forall tc \in TC \big( tc \in \mathcal{P}(F) \big) $ } \Comment{Ensure each test case is a subset of F}
|
|
|
|
% \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 { Check that at each single failure mode in the {\fg} is
|
|
included as a test case.}
|
|
%\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 \wedge f2) \not\in (\forall c) \;such\;that\; (f1,f2 \in F)) \wedge ( \{f1,f2\} \in \bigcup TC) \wedge ({DoubleFaultChecking} = TRUE)$ }
|
|
\Comment { If ${DoubleFaultChecking}$ is required, check that all possible double failure modes in the {\fg} (see section~\ref{sec:unitarystate}) are included
|
|
as a test cases.}
|
|
\State \textbf{return} $TC$
|
|
\end{algorithmic}
|
|
\end{algorithm}
|
|
%} % end footnotesize
|
|
%
|
|
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
|
|
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 { define the function $Analyse : tc \rightarrow r $ }
|
|
\Comment { This analysis is a human activity, FMEA, i.e. 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 FMEA applied in the localised 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
|
|
\State \textbf{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,
|
|
a `result' will exist for each `test case'.
|
|
%
|
|
Each result will be described from the perspective of %{\wrt} to
|
|
the {\fg}, not the members of it i.e. 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.
|
|
%%
|
|
|
|
%
|
|
A set of
|
|
results corresponding to our test cases is now available.
|
|
%
|
|
These share a common index value ($j$ in the algorithm description).
|
|
%
|
|
These results are the failure modes of the {\fg}.
|
|
%
|
|
\fmmdgloss
|
|
%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, results which have a common failure symptom from the perspective of the operation of the {\fg}.
|
|
%
|
|
Let set $\mathcal{SP}$ be the set of all symptoms,
|
|
and $\mathcal{R}$ be the set of all test case results.
|
|
%
|
|
The function $fcs$ is defined 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.
|
|
A set $SP$, the symptoms of failure, is obtained.
|
|
%
|
|
\ifthenelse {\boolean{paper}}
|
|
{
|
|
Component failure modes must be mutually exclusive.
|
|
\fmmdglossMUTEX
|
|
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 is linked to more than one symptom
|
|
%set <-------------------------------------------- HOW did the word set get in here!!!!!!!! Totally screwed up the meaning 26SEP2013
|
|
enforces the `unitary state failure mode constraint' for derived components (see section~\ref{sec:unitarystate}).
|
|
}
|
|
\fmmdgloss
|
|
%% 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.
|
|
The function $cdc$ is defined 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.
|
|
A
|
|
derived~component $DC$, which has its own set of failure~modes has been created.
|
|
%
|
|
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} the attribute of abstraction level $\abslev$ can be assigned to
|
|
components, where $\abslev$ is a natural number, ($\abslev \in \mathbb{N}_0$).
|
|
%
|
|
For a base component, let the abstraction level be zero.
|
|
%
|
|
The symptom abstraction process %is applied giving
|
|
gives a $\dc$,
|
|
this 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}
|
|
|
|
Since 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.
|
|
To go back to the sound system analogy (see section~\ref{sec:cdplayer}), it may have
|
|
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}
|
|
|
|
Since 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 the tree is traversed upwards.
|
|
%
|
|
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 Failure in Time(FIT)\cite{en61508}
|
|
levels can be automatically calculated.
|
|
\fmmdgloss
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|