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

Rainy Sunday....

Browse Source 
waiting for JBN3
This commit is contained in:
Robin Clark 2011-06-12 13:17:52 +01:00
parent 3daaa71f41
commit dd66f7af4c
3 changed files with 438 additions and 146 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

2
fmmd_concept/System_safety_2011/Makefile
View File

@ -1,5 +1,5 @@
DIAPNG=component.png fmmd_env_op_uml.png master_uml.png
DIAPNG=component.png fmmd_env_op_uml.png master_uml.png pd.png
%.png:%.dia

535
fmmd_concept/System_safety_2011/submission.tex
View File

@ -1,14 +1,16 @@
\documentclass[twocolumn]{article}
%\documentclass[a4paper,10pt]{report}
\usepackage{graphicx}
\usepackage{fancyhdr}
\usepackage{tikz}
\usetikzlibrary{shapes,snakes}
\usepackage{amsfonts,amsmath,amsthm}
\usetikzlibrary{shapes.gates.logic.US,trees,positioning,arrows}
%\input{../style}
\usepackage{ifthen}
\usepackage{lastpage}
\usetikzlibrary{shapes,snakes}
\newboolean{paper}
\setboolean{paper}{true} % boolvar=true or false
@ -36,6 +38,7 @@ failure mode of the component or sub-system}}}
\newcommand{\frategloss}{\glossary{name={failure rate}, description={The number of failure within a population (of size N), divided by N over a given time interval}}}
\newcommand{\pecgloss}{\glossary{name={PEC},description={A Programmable Electronic controller, will typically consist of sensors and actuators interfaced electronically, with some firmware/software component in overall control}}}
\newcommand{\bcfm}{base~component~failure~mode}
\def\layersep{2.5cm}
\begin{document}
\pagestyle{fancy}
@ -48,7 +51,7 @@ failure mode of the component or sub-system}}}
\lhead{Developing a rigorous bottom-up modular static failure mode modelling methodology}
% numbers at outer edges
\pagenumbering{arabic} % Arabic page numbers hereafter
\author{R.P.Clark$^\star$ , Andrew~Fish$^\dagger$ , John~Howse$^\dagger$ , Chris Garret$^\dagger$ \\
\author{R.P.Clark$^\star$ , A.~Fish$^\dagger$ , C.~Garret$^\dagger$, J.~Howse$^\dagger$ \\
$^\star${\em Energy Technology Control, 25 North Street, Lewes, BN7 2PE, UK} \and $^\dagger${\em University of Brighton, UK}
}
@ -60,9 +63,10 @@ failure mode of the component or sub-system}}}
The certification process of safety critical products for European and
other international standards often involve environmental stress,
endurance and Electro Magnetic Compatibility (EMC) testing. Theoretical, or 'static testing',
is often also required. In general this will reveal modifications that must be made to
is often also required. In general static testing will reveal modifications that must be made to
improve the product safety, or identify theoretical weaknesses in the design.
This paper proposes a new theoretical methodology for creating failure mode models of safety critical systems.
This paper proposes a new theoretical methodology for creating failure mode models of % safety critical i
systems.
It has a common notation for mechanical, electronic and software domains and is modular and hierarchical.
These properties provide advantages in rigour and efficiency when compared to current methodologies.
}
@ -76,11 +80,14 @@ We briefly analyse the four current methodologies.
\subsubsection{Fault Tree Analysis (FTA)}
FTA is a top down methodology in which a diagram is drawn for
each undesirable top level event, presenting the conditions that must arise to cause
the event. It is suitable for large complicated systems with few undesirable top
level events and focuses on those events considered most important or most catastrophic.
each undesirable top level failure, presenting the conditions that must arise to cause
the event.
%
It is suitable for large complicated systems with few undesirable top
level failures and focuses on those events considered most important or most catastrophic.
%
Effects of duplication/redundancy of safety systems can be readily assessed.
It uses notations that are readily understood by engineers.
It uses notations that are readily understood by engineers (logic symbols from digtal electroics and a fault hierarchy).
However, it cannot guarantee to model all base component failure modes
or be used to determine system level errors other than those modelled.
Each diagram is a separate model, creating duplication of modelled elements,
@ -90,8 +97,9 @@ support for environmental and operational states.
\subsection{Fault Mode Effects Analysis FMEA)}
FMEA is used principally in manufacturing.
Each defect is assessed by its cost to repair and its frequency, using a
failure mode ratio. A list of failures and their cost is generated.
Each defect is assessed by its cost to repair and its frequency.%, using a
%failure mode ratio.
A list of failures and their cost is generated.
It is easy to identify single component failure to system failure scenarios
and an estimate of product reliability can be calculated. It cannot focus on
component interactions that cause system failure modes or determine potential
@ -123,8 +131,8 @@ via self checking statistical mitigation.
\subsection{Summary of Defeciencies in Current Methods}
\subsubsection{Top Down approach: FTA} The top down technique FTA, introduces the possibility of missing base component
level failure modes~\cite{faa}[Ch.9]. Also one FTA tree is drawn for each top level
event, leading to repeated work, with limited ability for cross checking/model validation.
level failure modes~\cite{faa}[Ch.9]. Since one FTA tree is drawn for each top level
event, this leads to repeated work, with limited ability for cross checking/model validation.
\subsubsection{Bottom-up approach: FMEA, FMECA, FMEDA}
@ -140,7 +148,7 @@ is $N \times K$. To examine the effect that one failure mode has on all
the other components\footnote{A %base
component failure will typically affect the sub-system
it is part of, and create a failure effect at the SYSTEM level.}
will be $(N-1) \times N \times K$, in effect a very large set cross product.
will be $(N-1) \times N \times K$.%, in effect a very large set cross product.
If $E$ is the number of environmental conditions to consider
in a system, and $A$ the number of applied states (or modes of the SYSTEM),
the job of the bottom-up analyst is presented with two
@ -155,31 +163,31 @@ To look in detail at a half of a million test cases is obviously impractical.
% Requirements for an improved methodology The deficiencies identified in the
% current methodologies are used to establish criteria for an improved methodology.
\paragraph{Reasoning distance - complexity and reach-ability.}
Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
working heuristically. A base component failure will typically
be conceptually removed by several stages from a top level event.
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
that must interact to reach the top level event.
Where $C$ represents the set of components in a failure mode causation chain,
$c_i$ represents a component in $C$ and
the function $fm$ returns the failure modes for a given component, equation
\ref{eqn:complexity}, returns the `reasoning~distance'.
\begin{equation}
R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
\label{eqn:complexity}
\end{equation}
The reasoning distance is a value representing the number of failure modes
to consider to rigorously determine the causation chain
from the base component failure to the SYSTEM level event.
The reasoning distance serves to show that when the causes of a top level
event are completely determined, a large amount of work not
typical of heuristic or intuitive interpretation is required.
% could have a chapter on this.
% take a circuit or system and follow all the interactions
% to the components that cause the system level event.
% \paragraph{Reasoning distance - complexity and reach-ability.}
% Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
% working heuristically. A base component failure will typically
% be conceptually removed by several stages from a top level event.
% The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
% that must interact to reach the top level event.
% Where $C$ represents the set of components in a failure mode causation chain,
% $c_i$ represents a component in $C$ and
% the function $fm$ returns the failure modes for a given component, equation
% \ref{eqn:complexity}, returns the `reasoning~distance'.
% \begin{equation}
% R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
% \label{eqn:complexity}
% \end{equation}
%
% The reasoning distance is a value representing the number of failure modes
% to consider to rigorously determine the causation chain
% from the base component failure to the SYSTEM level event.
%
% The reasoning distance serves to show that when the causes of a top level
% event are completely determined, a large amount of work not
% typical of heuristic or intuitive interpretation is required.
% % could have a chapter on this.
% % take a circuit or system and follow all the interactions
% % to the components that cause the system level event.
\paragraph{Multiple Events from one base component failure mode}
A base component failure may potentially cause more than one
@ -189,21 +197,21 @@ a {\bcfm} and not investigate other possibilities.
%\section{Requirements for a new static failure mode Analysis methodology}
\section{A wish list for a failure mode methodology}
From the deficiencies outlined above, we can form a wish list for a better methodology.
\section{Desireable Criteria for a failure mode methodology}
From the deficiencies outlined above, ideally we can form a wish list for a better methodology.
{ \small
\begin{itemize}
\item It must address the state explosion problem.
\item It must ensure that all component failure modes be considered in the model.
\item It should be easy to integrate mechanical, electronic and software models \cite{sccs}[pp.287].
\item It should be re-usable, in that commonly used modules can be re-used in other designs/projects.
\item Address the state explosion problem.
\item Ensure that all component failure modes be considered in the model.
\item Be easy to integrate mechanical, electronic and software models \cite{sccs}[pp.287].
\item Be re-usable, in that commonly used modules can be re-used in other designs/projects.
\item It should have a formal basis, that is to say, be able to produce mathematical traceability
for its results, such as error causation trees.%, reliability and safety statistics.
\item It should be easy to use, ideally using a
graphical syntax (as opposed to a formal symbolic/mathematical text based language).
\item From the top down, the failure mode model should follow a logical de-composition of the functionality
to smaller and smaller functional groupings \cite{maikowski}.
\item It must be possible for multiple (simultaneous) failure modes to be modelled.% from the base component level up.
%\item It should be easy to use, ideally using a
%graphical syntax (as opposed to a formal symbolic/mathematical text based language).
%\item From the top down, the failure mode model should follow a logical de-composition of the functionality
%to smaller and smaller functional groupings \cite{maikowski}.
\item Be possible for multiple (simultaneous) failure modes to be modelled.% from the base component level up.
\end{itemize}
}
@ -230,46 +238,46 @@ to smaller and smaller functional groupings \cite{maikowski}.
%Development of the new methodology
%
% \section{An ontology of failure modes}
%
% An ontology is now developed of
% failure modes and their relationship to environmental factors,
% applied/operational states and the hierarchical nature inherent in product design,
% defining the relationships between the system as a whole, components,
% failure modes, operational and environmental states.
%
%
% Components have sets of failure modes associated with them.
% Failure modes for common components may be found in
% the literature~\cite{fmd91},~\cite{mil1991}.
% We can associate a component with its failure modes.
% This is represented in UML in figure \ref{fig:component_concept}.
%
% \begin{figure}[h]
% \centering
% \includegraphics[width=200pt,keepaspectratio=true]{./component.png}
% % component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76
% \caption{Component with failure modes UML diagram}
% \label{fig:component_concept}
% \end{figure}
\section{An ontology of failure modes}
An ontology is now developed of
failure modes and their relationship to environmental factors,
applied/operational states and the hierarchical nature inherent in product design,
defining the relationships between the system as a whole, components,
failure modes, operational and environmental states.
Components have sets of failure modes associated with them.
Failure modes for common components may be found in
the literature~\cite{fmd91},~\cite{mil1991}.
We can associate a component with its failure modes.
This is represented in UML in figure \ref{fig:component_concept}.
\begin{figure}[h]
\centering
\includegraphics[width=200pt,keepaspectratio=true]{./component.png}
% component.:wq: 467x76 pixel, 72dpi, 16.47x2.68 cm, bb=0 0 467 76
\caption{Component with failure modes UML diagram}
\label{fig:component_concept}
\end{figure}
\subsection{Modular Design}
When designing a system from the bottom-up, small groups of components are selected to perform
simple functions. These can be termed {\fgs}.
When the failure mode behaviour, or symptoms of failure
of a {\fg} are determined, it can be treated as a component in its own right.
% Functional groups
% are then brought together to form more complex and higher level {\fgs}.
Used in this way the {\fg} has become a {\dc}. The symptoms of failure
of the {\fg} can be considered the failure modes of its {\dc}.
Derived~Components can be used to create higher level {\fgs}.
Repeating this process will lead to identify-able higher level
groups, often referred to as sub-systems. We can call the entire collection/hierarchy
of sub-systems the SYSTEM.
%
% \subsection{Modular Design}
%
% When designing a system from the bottom-up, small groups of components are selected to perform
% simple functions. These can be termed {\fgs}.
% When the failure mode behaviour, or symptoms of failure
% of a {\fg} are determined, it can be treated as a component in its own right.
%
% % Functional groups
% % are then brought together to form more complex and higher level {\fgs}.
% Used in this way the {\fg} has become a {\dc}. The symptoms of failure
% of the {\fg} can be considered the failure modes of its {\dc}.
% Derived~Components can be used to create higher level {\fgs}.
% Repeating this process will lead to identify-able higher level
% groups, often referred to as sub-systems. We can call the entire collection/hierarchy
% of sub-systems the SYSTEM.
\subsection{Environmental Conditions, Operational States}
@ -324,9 +332,9 @@ Operational states are conditions that apply to some functional groups, not indi
%
%\paragraph{UML Model of FMMD Analysis}
%
The UML diagram in figure \ref{fig:env_op_uml}, shows the data
relationships between {\fgs} and operational states, and component
failure modes and environmental factors.
% The UML diagram in figure \ref{fig:env_op_uml}, shows the data
% relationships between {\fgs} and operational states, and component
% failure modes and environmental factors.
% \begin{figure}[h]
@ -337,16 +345,16 @@ failure modes and environmental factors.
% \label{fig:env_op_uml}
% \end{figure}
%
% \begin{figure}[h]
% \centering
% \includegraphics[width=200pt]{./fmmd_env_op_uml.png}
% % fmmd_env_op_uml.png: 816x246 pixel, 72dpi, 28.79x8.68 cm, bb=0 0 816 246
% \caption{UML model of failure mode ontology}
% \label{fig:env_op_uml}
% \end{figure}
\begin{figure}[h]
\centering
\includegraphics[width=200pt]{./fmmd_env_op_uml.png}
% fmmd_env_op_uml.png: 816x246 pixel, 72dpi, 28.79x8.68 cm, bb=0 0 816 246
\caption{UML model of failure mode ontology}
\label{fig:env_op_uml}
\end{figure}
%This is because environmental conditions will apply SYSTEM wide,
%This is because environmental \def\layersep{2.5cm}conditions will apply SYSTEM wide,
%but may only affect specific components.
%DEVELOP UML MODELS
@ -361,8 +369,8 @@ These are collected into functional groups
and each component failure mode (and optionally combinations) are considered in the
context of the {\fg}. These are termed `test~cases'. For each test~case
there will be a corresponding failure mode, from the perspective of the {\fg}.
A symptom collection stage will now be applied. Here common symptoms are collected
from the results of the test~cases.
A symptom collection stage is then applied. Here common symptoms are collected
from the results of the test~cases.Diagram1
With a collection of the {\fg} failure symptoms, we can now create a {\dc}.
The failure modes of this new {\dc} are the symptoms of the {\fg} it was derived from.
@ -370,13 +378,258 @@ By using {\dcs} in higher level functional groups, a hierarchy can be built repr
the failure mode behaviour of a SYSTEM.
\subsection{Re-Factoring the UML Model}
\subsection{FMMD analysis Example: A Voltage/Potential Divider}
\begin{figure}
\centering
\includegraphics[width=125pt,keepaspectratio=true]{./pd.png}
% pd.png: 364x241 pixel, 72dpi, 12.84x8.50 cm, bb=0 0 364 241
\caption{Potential Divider Circuit}
\label{fig:pd}
\end{figure}
The UML models thus far % in this
have been used to develop the ontology. % data relationships required to perform FMMD analysis.
We can now re-organise and rationalise the UML model.
We want to be able to use {\dcs} in functional groups.
It therefore makes sense for {\dc} to inherit {\em component}.
We consider here an example functional group, the potential divider
which consists of two resistors used to provide a voltage
intermediate of its supply and ground rails.
%It consists of two resistors.
%
%A functional group, is an ideally small in number collection of components,
%that interact to provide
%a function or task within a system.
%As the resistors work to provide a specific function, that of a potential divider,
%we can treat them as a functional group. i
The potential divider `functional~group' has two members, $R1$ and $R2$.
Using the EN298 specification for resistor failure ~\cite{en298}[App.A]
we can assign the failure modes of $OPEN$ and $SHORT$ to each of the resistors.
This is shown as a graph in figure \ref{fig:rdag}.
%\ifthenelse {\boolean{dag}}
{
We can now represent a resistor in terms of its failure modes as a directed acyclic graph (DAG)
(see figure \ref{fig:rdag}).
\begin{figure}[h+]
\centering
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
\tikzstyle{every pin edge}=[<-,shorten <=1pt]
\tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
\tikzstyle{component}=[fmmde, fill=green!50];
\tikzstyle{failure}=[fmmde, fill=red!50];
\tikzstyle{symptom}=[fmmde, fill=blue!50];
\tikzstyle{annot} = [text width=4em, text centered]
\node[component] (R) at (0,-3) {$R$};
\node[failure] (RSHORT) at (\layersep,-2) {$R_{SHORT}$};
\node[failure] (ROPEN) at (\layersep,-4) {$R_{OPEN}$};
\path (R) edge (RSHORT);
\path (R) edge (ROPEN);
\end{tikzpicture}
\caption{DAG representing a reistor and its failure modes}
\label{fig:rdag}
\end{figure}
}
%{
%}
Thus or the potential divider in the circuit in figure~\ref{fig:pd},
$R1$ has failure modes $\{R1\_OPEN, R1\_SHORT\}$ and $R2$ has failure modes $\{R2\_OPEN, R2\_SHORT\}$.
%\clearpage
\section{Failure Mode Analysis of the Potential Divider}
%\ifthenelse {\boolean{dag}}
{
Modelling the two resistors as a functional group, we present this as a directed graph.
%failure modes, taken from the components R1 and R2,
%in the potential divider, shown
in figure \ref{fig:fg1dag}.
\begin{figure}
\centering
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
\tikzstyle{every pin edge}=[<-,shorten <=1pt]
\tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
\tikzstyle{component}=[fmmde, fill=green!50];
\tikzstyle{failure}=[fmmde, fill=red!50];
\tikzstyle{symptom}=[fmmde, fill=blue!50];
\tikzstyle{annot} = [text width=4em, text centered]
\node[component] (R1) at (0,-4) {$R_1$};
\node[component] (R2) at (0,-6) {$R_2$};
\node[failure] (R1SHORT) at (\layersep,-2) {$R1_{SHORT}$};
\node[failure] (R1OPEN) at (\layersep,-4) {$R1_{OPEN}$};
\node[failure] (R2SHORT) at (\layersep,-6) {$R2_{SHORT}$};
\node[failure] (R2OPEN) at (\layersep,-8) {$R2_{OPEN}$};
\path (R1) edge (R1SHORT);
\path (R1) edge (R1OPEN);
\path (R2) edge (R2SHORT);
\path (R2) edge (R2OPEN);
% Potential divider failure modes
%
%\node[symptom] (PDHIGH) at (\layersep*2,-4) {$PD_{HIGH}$};
%\node[symptom] (PDLOW) at (\layersep*2,-6) {$PD_{LOW}$};
%\path (R1OPEN) edge (PDHIGH);
%\path (R2SHORT) edge (PDHIGH);
%\path (R2OPEN) edge (PDLOW);
%\path (R1SHORT) edge (PDLOW);
\end{tikzpicture}
\caption{DAG representing the functional group `Potential Divider'}
\label{fig:fg1dag}
\end{figure}
}
%{
%}
We can now look at each of these base component failure modes,
and determine how they will affect the operation of the potential divider.
%Each failure mode scenario we look at will be given a test case number,
%which is represented on the diagram, with an asterisk marking
%which failure modes is modelling (see figure \ref{fig:fg1a}).
%\ifthenelse {\boolean{dag}}
{
For this example we can look at single failure modes only.
For each failure mode in our {\fg} `potential~divider'
we can assign a test case number (see table \ref{pdfmea}).
Each test case is analysed to determine the `symptom'
on the potential dividers' operation. For instance
were the resistor $R_1$ to go open, the circuit would not be grounded and the
voltage output from it would be the +ve supply rail.
This would mean the symptom of the failed potential divider, would be that it
gives an output high voltage reading. We can now consider the {\fg}
as a component in its own right, and its symptoms as its failure modes.
From table \ref{pdfmea} we can see that resistor
failures modes lead to some common `symptoms'.
By drawing connecting lines in a graph, from the failure modes to the symptoms
we can show the relationships between the component failure modes and resultant symptoms.
%The {\fg} can now be considered a derived component.
This is represented in the DAG in figure \ref{fig:fg1adag}.
\begin{figure}[h+]
\centering
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
\tikzstyle{every pin edge}=[<-,shorten <=1pt]
\tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
\tikzstyle{component}=[fmmde, fill=green!50];
\tikzstyle{faitinylure}=[fmmde, fill=red!50];
\tikzstyle{symptom}=[fmmde, fill=blue!50];
\tikzstyle{annot} = [text width=4em, text centered]
\node[component] (R1) at (0,-4) {$R_1$};
\node[component] (R2) at (0,-6) {$R_2$};
\node[failure] (R1SHORT) at (\layersep,-2) {$R1_{SHORT}$};
\node[failure] (R1OPEN) at (\layersep,-4) {$R1_{OPEN}$};
\node[failure] (R2SHORT) at (\layersep,-6) {$R2_{SHORT}$};
\node[failure] (R2OPEN) at (\layersep,-8) {$R2_{OPEN}$};
\path (R1) edge (R1SHORT);
\path (R1) edge (R1OPEN);
\path (R2) edge (R2SHORT);
\path (R2) edge (R2OPEN);
% Potential divider failure modes
%
\node[symptom] (PDHIGH) at (\layersep*2,-4) {$PD_{HIGH}$};
\node[symptom] (PDLOW) at (\layersep*2,-6) {$PD_{LOW}$};
\path (R1OPEN) edge (PDHIGH);
\path (R2SHORT) edge (PDHIGH);
\path (R2OPEN) edge (PDLOW);
\path (R1SHORT) edge (PDLOW);
\end{tikzpicture}
\caption{Failure symptoms of the `Potential Divider'}
\label{fig:fg1adag}
\end{figure}
}
%{
%}
\begin{table}[ht]
\caption{Potential Divider: Failure Mode Effects Analysis: Single Faults} % title of Table
\centering % used for centering table
\begin{tabular}{||l|c|c|l|l||}
\hline \hline
\textbf{Test} & \textbf{Pot.Div} & \textbf{ } & \textbf{Symptom} \\
\textbf{Case} & \textbf{Effect} & \textbf{ } & \textbf{Description} \\
% R & wire & res + & res - & description
\hline
\hline
TC1: $R_1$ SHORT & LOW & & LowPD \\
TC2: $R_1$ OPEN & HIGH & & HighPD \\ \hline
TC3: $R_2$ SHORT & HIGH & & HighPD \\
TC4: $R_2$ OPEN & LOW & & LowPD \\ \hline
\hline
\end{tabular}
\label{pdfmea}
\end{table}
%\ifthenelse {\boolean{dag}}
{
We can now represent the potential divider as a {\dc}.
Because have its symptoms or failure mode behaviour,
we can treat these as the failure modes of a a new {\dc}.
We can represent that as a DAG (see figure \ref{fig:dc1dag}).
\begin{figure}[h+]
\centering
\begin{tikzpicture}[shorten >=1pt,->,draw=black!50, node distance=\layersep]
\tikzstyle{every pin edge}=[<-,shorten <=1pt]
\tikzstyle{fmmde}=[circle,fill=black!25,minimum size=30pt,inner sep=0pt]
\tikzstyle{component}=[fmmde, fill=green!50];
\tikzstyle{failure}=[fmmde, fill=red!50];
\tikzstyle{symptom}=[fmmde, fill=blue!50];
\tikzstyle{annot} = [text width=4em, text centered]
\node[component] (PD) at (0,-3) {$PD$};
\node[symptom] (PDHIGH) at (\layersep,-2) {$PD_{HIGH}$};
\node[symptom] (PDLOW) at (\layersep,-4) {$PD_{LOW}$};
\path (PD) edge (PDHIGH);
\path (PD) edge (PDLOW);
\end{tikzpicture}
\caption{DAG representing a Potential Divider (PD) its failure symptoms}
\label{fig:dc1dag}
\end{figure}
}
%{
%}
%Because the derived component is defined by its failure modes and
%the functional group used to derive it, we can use it
As we have a set of failure modes for the potential divider {\dc},
we can use it
as a building block for other {\fgs}.% in the same way as we used the resistors $R1$ and $R2$.
Note that number of base failure modes, four, is reduced to two in the {\dc}.
Not only have we avoided the state explosion problem of having to
check $R1$ and $R2$ against all other components in the system they may belong to,
by making it a derived component, we have reduced the number of errors we need to consider at higher levels
of analysis.
% \subsection{Re-Factoring the UML Model}
%
% The UML models thus far % in this
% have been used to develop the ontology. % data relationships required to perform FMMD analysis.
% We can now re-organise and rationalise the UML model.
% We want to be able to use {\dcs} in functional groups.
% It therefore makes sense for {\dc} to inherit {\em component}.
@ -389,21 +642,21 @@ It therefore makes sense for {\dc} to inherit {\em component}.
% \label{fig:refactored_uml}
% \end{figure}
\begin{figure}[h]
\centering
\includegraphics[width=200pt]{./master_uml.png}
% master_uml.png: 700x462 pixel, 72dpi, 24.69x16.30 cm, bb=0 0 700 462
\caption{Re-factored UML Diagram }
\label{fig:refactored_uml}
\end{figure}
The re-factored UML diagram is shown in figure \ref{fig:refactored_uml}; with this structure
{\dcs} can be
used to build {\fgs} at a higher level. In this manner we
can build a hierarchical model with each layer consisting of
components derived from the functional groups of derived components,
until we arrive at a SYSTEM level.
The symptoms of the {\fg} at the top represent the SYSTEM failure modes.
% \begin{figure}[h]
% \centering
% \includegraphics[width=200pt]{./master_uml.png}
% % master_uml.png: 700x462 pixel, 72dpi, 24.69x16.30 cm, bb=0 0 700 462
% \caption{Re-factored UML Diagram }
% \label{fig:refactored_uml}
% \end{figure}
%
% The re-factored UML diagram is shown in figure \ref{fig:refactored_uml}; with this structure
% {\dcs} can be
% used to build {\fgs} at a higher level. In this manner we
% can build a hierarchical model with each layer consisting of
% components derived from the functional groups of derived components,
% until we arrive at a SYSTEM level.
% The symptoms of the {\fg} at the top represent the SYSTEM failure modes.
%From the ontology, a set of rules for converting the {\fgs}
@ -414,23 +667,25 @@ The symptoms of the {\fg} at the top represent the SYSTEM failure modes.
%On collecting
%symptoms from this, we are left with the top level, or system level, failure modes.
\paragraph{Diagramatic Notation based on Euler Diagrams}
The model is presented in a diagrammatic notation that has been
designed to be intuitive and understandable.
%
It uses well tested
visual techniques to represent the elements of the model and their
relationships.
%
Software support for the development of models in this
notation has been designed and proof-of-concept tools have been implemented.
% \paragraph{Diagramatic Notation based on Euler Diagrams}
%
% The model is presented in a diagrammatic notation that has been
% designed to be intuitive and understandable.
% %
% It uses well tested
% visual techniques to represent the elements of the model and their
% relationships.
% %
% Software support for the development of models in this
% notation has been designed and proof-of-concept tools have been implemented.
\subsection{Justification of wishlist}
\subsection{Evaluation against Desirable Criteria}
By applying the methodology in section \ref{fmmdproc}, the wishlist can
now be evaluated for the proposed FMMD methodology.
%By applying the methodology in section \ref{fmmdproc}, the wishlist can
%now be evaluated for the proposed FMMD methodology.
We can now evaluate the FMMD method using the criteria in section \ref{fmmdproc}.
{ \small
\begin{itemize}
@ -462,7 +717,7 @@ or even in other projects where the same {\dc} is used.
for its results}
Because the failure mode of a SYSTEM is a hierarchy of {\fg}s and derived components
SYSTEM level failure modes are traceable back down the fault tree to
component level failure modes. This provides causation trees \cite{sccs} or, minimal cut sets
component level failure modes. This provides causation trees \cite{sccs} or, minimal cut sets~\cite{nasafta}[Ch.1pp3]
for all SYSTEM failure modes.
\item{ It should be capable of producing reliability and danger evaluation statistics.}
@ -513,7 +768,7 @@ mechanical and software elements in one integrated model.
\today
%
{ \tiny
{ \small
\bibliographystyle{plain}
\bibliography{vmgbibliography,mybib}
}

47
fmmd_concept/fmmd_concept.tex
View File

@ -309,8 +309,45 @@ trees can be derived. Maintainability and consistency cannot therefore be automa
\item No possibility to model base component level double failure modes.
\end{itemize}
\subsection { FMEA }
\subsection { Current Bottom up methodologies - FMEA, FMECA, FMEDA }
The state explosion problem for bottom-up
can be theoretically reduced by taking the path from
the base component failure mode, through the signal path~\cite{garrett}
and considering all failure modes for each component on the path.
This thinking is discussed in the concept of a `Reasoning~distance' in section \ref{sec:rd}.
%
In practise, this following to all components on the signal path, will not be done.
Typically simpler scenarios will be used where the effect of
the component failure will be considered in isolation and then applied to the signal path.
\paragraph{Reasoning distance - complexity and reach-ability.}
Tracing a component level failure up to a top level event, without the rigour accompanying state explosion, involves
working heuristically. A base component failure will typically
be conceptually removed by several stages from a top level event.
The `reasoning~distance' $R_D$ can be calculated by summing the failure modes in each component, for all components
that must interact to reach the top level event.
Where $C$ represents the set of components in a failure mode causation chain,
$c_i$ represents a component in $C$ and
the function $fm$ returns the failure modes for a given component, equation
\ref{eqn:complexity}, returns the `reasoning~distance'.
\begin{equation}
R_D = \sum_{i=1}^{|C|} |{fm(c_i)}| %\; where \; c \in C
\label{eqn:complexity}
\end{equation}
The reasoning distance is a value representing the number of failure modes
to consider to rigorously determine the causation chain
from the base component failure to the SYSTEM level event.
The reasoning distance serves to show that when the causes of a top level
event are completely determined, a large amount of work not
typical of heuristic or intuitive interpretation is required.
% could have a chapter on this.
% take a circuit or system and follow all the interactions
% to the components that cause the system level event.
\subsubsection{FMEA}
\label{pfmea}
This is an early static analysis methodology, and concentrates
on SYSTEM level errors which have been investigated.
@ -329,7 +366,7 @@ This gives in effect
a prioritised `to~do~list', with higher $RPN$ values being the most urgent.
\subsubsection{ FMEA weaknesses }
\paragraph{ FMEA weaknesses }
\begin{itemize}
\item Possibility to miss the effects of base component failure modes at SYSTEM level.
(because the its each individual component, not all its failure modes, that are considered for analysis).
@ -377,7 +414,7 @@ Again this essentially produces a prioritised `to~do' list.
\subsubsection{ FMECA weaknesses }
\paragraph{ FMECA weaknesses }
\begin{itemize}
\item Possibility to miss the effects of failure modes at SYSTEM level.
\item Possibility to miss environmental affects.
@ -406,7 +443,7 @@ described in EN61508~\cite{en61508}[Part 2 App C].
The following gives an outline of the procedure.
\subsubsection{Two statistical perspectives}
\paragraph{Two statistical perspectives}
\ifthenelse {\boolean{paper}}
{
FMEDA is a statistical analysis methodology and is used from one of two perspectives,
@ -667,7 +704,7 @@ and its international analog standard IOC5108.
\end{itemize}
%AND then how we can solve all there problems
\section{A wish list for a failure mode methodology}
\section{Desirable Criteria for a failure mode methodology}
\begin{itemize}
\item All component failure modes must be considered in the model.
\item It should be easy to integrate mechanical, electronic and software models \cite{sccs}[pp.287].