1298 lines
54 KiB
TeX
1298 lines
54 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.
|
|
%
|
|
%This section decribes the algorithm for performing one step of
|
|
%FMMD analysis
|
|
%analysing a {\fg} and determining from it a {\dc}.
|
|
%
|
|
%Algorithms using set theory describe the process.
|
|
%An overview of the FMMD process is presented and it is then compared to
|
|
%diagnostic analysis (fault finding).
|
|
%This is followed by justification for using a bottom-up, forward search
|
|
%approach, along with modularisation.
|
|
%A theoretical example of FMMD using set theory is given following on to
|
|
%a description of the process presented as an algorithm.
|
|
%for performing FMMD is then presented.
|
|
|
|
%
|
|
% \section{FMMD as a process.}
|
|
%
|
|
% % In FMMD we take a group of components with a functional purpose, apply
|
|
% % FMEA, and then determine how the {\fg} can fail.
|
|
% % We determine the common symptoms of failure of the {\fg}, and then
|
|
% % create a new {\dc} which has, as its failure modes, the symptoms we determined.
|
|
%
|
|
% \paragraph{FMMD and failure mode models.}
|
|
%
|
|
% To perform FMMD a {\fg} (a collection of components) is chosen
|
|
% FMEA is applied to it.
|
|
% %
|
|
% %In this way, we determine how that {\fg} can fail.
|
|
% This gives us a set of failure modes for the {\fg}.
|
|
% %
|
|
% The {\fg} is not viewed as a component, or module,
|
|
% and the FMEA results considered
|
|
% be its symptoms of failure.
|
|
% %
|
|
% Because component failures will often manifest themselves as the same symptoms of failure,
|
|
% we are able to collect common symptoms of failure for the {\fg}.
|
|
% %
|
|
% %
|
|
% With the collected common symptoms, we can treat the {\fg}
|
|
% as a component in its own right. We term this a `{\dc}'.
|
|
% %This new component being derived from the {\fg}.
|
|
% %
|
|
% %The `{dc}' can be thought of as a low~level sub-system.
|
|
% %The technique uses a graphical notation, based on Euler\cite{eulerviz} and Constraint diagrams\cite{constraint} to model failure modes and failure mode common symptom collection. The technique is designed for making building blocks for a hierarchical fault model.
|
|
% %
|
|
% Once the failure modes have been determined for a sub-system/{\dc},
|
|
% this {\dc} can be combined with others to form {\fgs} to model higher level sub-systems/{\dcs}.
|
|
% %
|
|
% In this way a hierarchy to represent the fault behaviour
|
|
% of a system can be built from the bottom~up. This process can continue
|
|
% until there is a complete hierarchy representing the failure mode
|
|
% behaviour of the entire system under analysis.
|
|
% %FMMD hierarchy
|
|
% Using the FMMD technique, the hierarchy is built from the bottom up to
|
|
% ensure complete failure mode coverage.
|
|
% Because the process is bottom-up, syntax checking and tracking can ensure that
|
|
% no component failure mode can be overlooked.
|
|
% Once a hierarchy is in place, it can be converted into a generic failure mode model.
|
|
% \fmmdgloss
|
|
% %
|
|
% %From the fault data model, automatic generation
|
|
% %of FTA \cite{nasafta} (Fault Tree Analysis) and minimal cuts sets \cite{nucfta} are possible.
|
|
% %Also statistical reliability/probability of failure~on~demand \cite{en61508} and MTTF (Mean Time to Failure) calculations can be produced
|
|
% %automatically\footnote{Where component failure mode statistics are available \cite{mil1991}}.
|
|
% %
|
|
% This chapter focuses on the process of converting {\fgs} to {\dcs}, or building the `blocks' of the FMMD hierarchy.
|
|
% We can term this stage in FMMD analysis as the `symptom abstraction' process.
|
|
% %The symptom abstraction or abstraction process, is the key process in creating an FMMD hierarchy.
|
|
% }
|
|
%\vspace{40pt}
|
|
% %\today
|
|
% \paragraph{Mutual exclusive property of the failure modes of a {\dc}}
|
|
% Because the symptoms have been collected from
|
|
% identical failure effects of the {\fg} they are mutually exclusive.
|
|
% That is to say no failure mode effects of a component of a {\fg}
|
|
% can be shared by a {\dc} failure mode.
|
|
% This ensures the mutually exclusive, or unitary state failure mode property, meaning
|
|
% the failure modes of a {\dc} are suitable for use in higher level {\fgs}.
|
|
%
|
|
% \subsection{Diagnostic analysis and Failure Mode Analysis}
|
|
% Fault finding is a closely related discipline to failure mode analysis.
|
|
% In diagnostic analysis, we generally start with a high level --- or system ---failure type.
|
|
% We trace this from the top, de-composing the systems until we come to
|
|
% a component or sub-system that has caused the failure.
|
|
% While there are similarities between diagnostic failure mode tracing and static failure mode analysis
|
|
% it is important to discuss the differences between them.
|
|
% %
|
|
%\subsection{Static Analysis}
|
|
%
|
|
%In the field of safety critical engineering, to comply with
|
|
%European Law, a product must be certified under the appropriate `EN' standard.
|
|
%Typically environmental stress, EMC, electrical stressing, endurance tests,
|
|
%software~inspections and project~management quality reviews are applied \cite{sccs}.
|
|
%
|
|
%Static testing is also applied. This is theoretical analysis of the design of the product from the safety
|
|
%perspective.
|
|
%%
|
|
%Three main methodologies are currently used,
|
|
%Statistical failure models, FMEA (Failure mode Effects Analysis) and FTA (Fault Tree Analysis).
|
|
%The FMMD process is a static modelling methodology, aimed primarily for design verification of
|
|
%safety critical systems.
|
|
%%
|
|
%However, FMMD also provides the mathematical framework
|
|
%to assist in the production of the three traditional methods of static analysis.
|
|
%From the model created by the FMMD methodology, statistical, FTA and FMEA models
|
|
%can be derived.
|
|
%FMMD can model electrical, mechanical and software failures using a common notation,
|
|
%and can thus model an integrated electro-mechanical software controlled system.
|
|
%
|
|
% \subsection{Top Down or Natural Trouble Shooting}
|
|
% We firstly look at the `natural' trouble shooting process.
|
|
% Fault finding is instinctively performed from the top-down.
|
|
% A faulty piece of equipment is examined and will have a
|
|
% symptom or specific fault.
|
|
% %
|
|
% The suspected area or sub-system within the
|
|
% equipment will be looked into next.
|
|
% %
|
|
% The trouble shooter will look for behaviour that is unusual or incorrect
|
|
% to determine the next area or sub~system to look into, each time
|
|
% moving to a more detailed lower level.
|
|
% Specific measurements
|
|
% and checks will be made, and finally a component or a low level sub-system
|
|
% will be found to be faulty.
|
|
% A natural fault finding process is thus top~down.
|
|
% Top down formal fault isolation/finding techniques for electronics are described in \cite{maikowski}.
|
|
% Fault tree analysis is a top down static failure mode analysis technique~\cite{nucfta,nasafta}.
|
|
% %%
|
|
% %% to fool the graphics insertion to make it compatible
|
|
% %% with thesis and papaer level directories.
|
|
% %%
|
|
% %% ln -s . symptom_ex_process
|
|
% %%
|
|
%
|
|
% %% insert diagram here
|
|
%
|
|
% \begin{figure}[h]
|
|
% \centering
|
|
% \includegraphics[width=300pt,bb=0 0 587 445,keepaspectratio=true]{./CH4_FMMD/top_down_de_comp.png}
|
|
% % top_down_de_comp.jpg: 587x445 pixel, 72dpi, 20.71x15.70 cm, bb=0 0 587 445
|
|
% \caption{Top Down Failure De-Composition Diagram}
|
|
% \label{fig:tdh}
|
|
% \end{figure}
|
|
%
|
|
% %%
|
|
% %% FMEA and FTA and safety engineering people used the term SUB_SYSTEM ALOT
|
|
% %% this study needs to use this term to keep the interested/in context.
|
|
% The term `sub-system' is typically used in top down methodologies.
|
|
% It has two equivalents in FMMD.
|
|
% Both {\fg} and {\dc} correspond to the top down concept of a `sub-system'.
|
|
% In FMMD a {\fg} becomes a {\dc} after analysis.
|
|
% The term sub-system will be used alongside both {\fg} and {\dc} where necessary.
|
|
%
|
|
% \subsection{Top-Down System De-Composition}
|
|
%
|
|
% A top down fault analysis system will take a system and divide it into
|
|
% several sub-systems, and determine the safety dependencies
|
|
% of the System on those sub-systems. In the case of large complicated
|
|
% systems, the sub-systems themselves may be broken down into simpler sub-systems.
|
|
% A top down hierarchy is shown in figure \ref{fig:tdh}.
|
|
%
|
|
% \subsection{FMMD - Bottom~up Analysis}
|
|
% The FMMD methodology does not follow the `natural fault finding' or top down approach,
|
|
% it instead works from the bottom up.
|
|
% Starting with a collection of base~components that form
|
|
% a simple functional group, the effect of all component error modes are
|
|
% examined, as to their effect on the functional group.
|
|
% %
|
|
% The effects on the functional group can then be collected as common symptoms,
|
|
% and now we may treat the functional group as a component, as it has a known set of failure modes.
|
|
% %
|
|
% By reusing the `components' derived from functional~groups, an entire
|
|
% hierarchical failure mode model of the system can be built.
|
|
% That is to say, using derived components in higher level functional groups,
|
|
% a hierarchy is naturally formed.
|
|
% %
|
|
% By working from the bottom up, we can trace all possible sources
|
|
% that could cause a particular mode of equipment failure.
|
|
% This means that at the design stage of a product all component failure
|
|
% modes must be considered. A benefit of FMMD is complete failure mode coverage.
|
|
% This also means that it is possible to obtain statistical estimates based on the known reliabilities
|
|
% of components~\cite{mil1991}.
|
|
% %It also means that every component failure mode must at the very least be considered.
|
|
|
|
|
|
%{
|
|
%The aims are
|
|
%\begin{itemize}
|
|
% \item To automate the process where possible
|
|
% \item To apply a documented trail for each analysis phase (determination of functional groups, and analysis of component failure modes on those groups)
|
|
% \item To use a modular approach so that analysed sub-systems can be re-used
|
|
% \item Automatically ensure no failure mode is unhandled
|
|
% \item To produce a data model from which FTA, FMEA and statistical failure models may be obtained automatically
|
|
%\end{itemize}
|
|
%}
|
|
%
|
|
|
|
|
|
%\vspace{0.3cm}
|
|
% \begin{table}[h]
|
|
% \center
|
|
% \begin{tabular}{||l|l||} \hline \hline
|
|
% {\em Definition } & {\em Description} \\ \hline
|
|
% System & A product designed to \\
|
|
% & work as a coherent entity \\ \hline
|
|
% Sub-system & A part of a system, \\
|
|
% -or- derived component & sub-systems may contain sub-systems. \\
|
|
% & derived~components may be derived \\
|
|
% & from derived components \\
|
|
% & Constraint: This object must have a defined set of failure~modes \\ \hline
|
|
% Failure mode & A way in which a system, \\
|
|
% & sub-system or component can fail \\ \hline
|
|
% Functional Group & A collection of sub-systems and/or \\
|
|
% & components that interact to \\
|
|
% & perform a specific function \\ \hline
|
|
% Symptom & A failure mode of a functional group, caused by \\
|
|
% & a combination of its component failure modes \\ \hline
|
|
% Base Component & Any bought in component, or \\
|
|
% & lowest level module/or part \\
|
|
% & Constraint: This object must have a defined set of failure~modes \\ \hline
|
|
% \hline
|
|
% \end{tabular}
|
|
% \caption{Symptom Extraction Definitions}
|
|
% \label{tab:symexdef}
|
|
% \end{table}
|
|
|
|
|
|
\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 simply FMEA analysis of systems.
|
|
%
|
|
The FMMD process stages are expanded upon below.
|
|
|
|
|
|
\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
|
|
%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}.
|
|
%
|
|
The aim of this 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 need not be concerned with
|
|
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 (i.e. as a {\dc}).
|
|
|
|
\paragraph{Environmental Conditions or Operational States.}
|
|
|
|
Each test case must 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 to a test case will be examined.
|
|
|
|
%As part of this analysis process,
|
|
To aid test repeatability, quality and audit trails, records should be kept
|
|
detailing not only each test case result along with its resultant
|
|
{\fg} failure mode, but the reasoning applied to obtain the analysis.
|
|
%
|
|
This data can be kept in the model as part of an analysis report.
|
|
%and could be used to
|
|
%automatically examine the effects of environmentally sourced common mode failure scenarios.
|
|
|
|
|
|
%%- A {\fg} may, in the case of an electronic circuit have
|
|
%%- applied states. For instance test modes, shutdown or lockout modes etc.
|
|
%%- which are inputs to the circuit.
|
|
%%- In this case each test case from the {\fg} must be analysed with
|
|
%%- respect to all these states.
|
|
%%-
|
|
%%- A mechanical device may be required to work in different
|
|
%%- temperature or pressure ranges for instance and its failure mode behaviour may
|
|
%%- change due to enviromental factors.
|
|
%%-
|
|
|
|
\paragraph{Symptom Identification.}
|
|
When all `test~cases' have been analysed, a second phase can be actioned. % applied.
|
|
%
|
|
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 and consider the 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 eight steps:
|
|
|
|
\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{
|
|
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,
|
|
we determine the failure~mode behaviour of the {\fg}.
|
|
%
|
|
This is a human process, applying FMEA for each test case.
|
|
%
|
|
Where specific environment 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}}.
|
|
%
|
|
\item The common~symptoms are now the fault mode behaviour of the {\fg}.
|
|
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{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.
|
|
% }
|
|
% {
|
|
|
|
\subsection{Single FMMD stage described as a `symptom~abstraction~process'}
|
|
|
|
|
|
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
|
|
that will be used in the description of FMMD
|
|
presented as an algorithm.
|
|
%
|
|
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 $$
|
|
|
|
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.
|
|
|
|
|
|
\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$).
|
|
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 {\fg} used to derive it.
|
|
Thus a derived component sourced from base components
|
|
will have an $\abslev$ value of 1.
|
|
%
|
|
%If $DC$ were to be included in a functional~group,
|
|
%that functional~group must be considered to be at a higher level of
|
|
%abstraction than a base level functional~group.
|
|
%
|
|
%In fact, if the abstraction level is enumerated,
|
|
%the functional~group must take the abstraction level
|
|
%of the highest assigned to any of its components.
|
|
%
|
|
%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 {\fgs}, a hierarchy is
|
|
naturally formed with the abstraction levels increasing with each tier.
|
|
\fmmdgloss
|
|
|
|
|
|
%\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
|
|
|
|
|
|
The algorithm, represented by the symbol `$\derivec$', has been broken down into five consecutive stages.
|
|
%These are described using the Algorithm environment in the next section \ref{algorithms}.
|
|
By defining the process and describing it using set theory. Constraints and
|
|
verification checks in the process are stated formally.
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
|
|
|
|
|
|
|
|
\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 derived~component, 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{\FG} \rightarrow \mathcal{P}\,\mathcal{G} $$
|
|
|
|
%
|
|
%%Let $FG$ be the set of components in the functional group under analysis, and $c$
|
|
%%be components that are members of it. This function returns a flat set of failure modes $F$.
|
|
%given by
|
|
%$$fm(FG) = F$$
|
|
%%%
|
|
%%% Algorithm 1
|
|
%%%
|
|
%
|
|
%%%-
|
|
%%%- A such that B is C
|
|
%%%-
|
|
%
|
|
%
|
|
%\begin{algorithm}[h+]
|
|
% ~\label{alg1}
|
|
%\caption{Determine Failure Modes: fm( $FG$ )} \label{alg11}
|
|
%\begin{algorithmic}[1]
|
|
%\REQUIRE {FG is a non empty set of components i.e. $ FG \in \mathcal{P}\,\mathcal{C} \wedge FG \neq \emptyset $. }
|
|
%\REQUIRE {Each component $c \in FG $ has a known set of failure modes i.e. $ \forall c \in FG \; \big( fm(c) \neq \emptyset \big)$.}
|
|
%
|
|
%%\STATE { Let $FG$ be a set of components } \COMMENT{The functional group should be chosen to be minimally sized collections of components that perform a specific function}
|
|
%
|
|
%\STATE { $ F := \emptyset $ } \COMMENT{Clear the set of failure modes}
|
|
%\FORALL { $c \in FG $ }
|
|
%\STATE { $F:= F \cup fm(c)$ } \COMMENT{Collect the failure modes from the component `c' and append them to $F$ }
|
|
%\ENDFOR
|
|
%
|
|
%\COMMENT {$F=fm(FG)$ is the set of all failure modes to consider for the functional~group $FG$}
|
|
%
|
|
%
|
|
%\RETURN { $F$ }
|
|
%
|
|
%%\hline
|
|
%%
|
|
%\end{algorithmic}
|
|
%\end{algorithm}
|
|
%
|
|
%Algorthim \ref{alg11} has taken a functional~group $FG$ and returned a set of failure~modes $F=fm(FG)$
|
|
%(given that each component has a known set of failure~modes).
|
|
The next task is to formulate `test cases'. These are a collection of combinations of these failure~modes 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$).
|
|
|
|
$$ 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}
|
|
|
|
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}.
|
|
% }
|
|
%%
|
|
%% Algorithm 2
|
|
%%
|
|
|
|
|
|
%%
|
|
%% Maybe need to iterate through each failure mode, adding a new test case
|
|
%% this would build up all single fault test cases.
|
|
%%
|
|
|
|
\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}$).
|
|
|
|
$$ 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 static failure mode reasoning
|
|
where possible.
|
|
%
|
|
When the 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.
|
|
|
|
$$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$.
|
|
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.
|
|
}
|
|
{
|
|
Note ensuring that no result belongs to more than one symptom
|
|
set enforces the `unitary state failure mode constraint' for derived components.
|
|
}
|
|
|
|
%% 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.
|
|
|
|
$$ 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.
|
|
\subsection{Hierarchical Simplification}
|
|
|
|
Because symptom abstraction collects 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.
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
%%%\section{Example Symptom Extraction}
|
|
%% There already is an example of the process before the algorithmic description
|
|
%%%This is a simplified version of the pt100 example in chapter \ref{pt100}.
|
|
|
|
%\vspace{40pt}
|
|
%\today
|
|
|
|
|
|
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%% %
|
|
..
|