89222b34b2
2012---and made minor alterations to CH4. J Howse said CH4 is finished !!!! Whooooooooooooooopppppppppppppppppppppppeeeeeeeeeeeeeeeeeeee!
1668 lines
54 KiB
TeX
1668 lines
54 KiB
TeX
\documentclass{beamer}
|
|
%\documentclass[handout]{beamer}
|
|
\title[Failure Mode Effects Analysis]{Failure Mode Effects Analysis\\A critical view}
|
|
\usetheme{Warsaw}
|
|
\usepackage[latin1]{inputenc}
|
|
\author{Robin Clark -- Energy Technology Control Ltd}
|
|
\institute{Brighton University}
|
|
\setbeamertemplate{footline}[page number]
|
|
|
|
|
|
%\newcommand{\fg}{\em functional~group}
|
|
%\newcommand{\fgs}{\em functional~groups}
|
|
\newcommand{\fg}{\em functional~grouping}
|
|
\newcommand{\fgs}{\em functional~groupings}
|
|
\newcommand{\fm}{\em failure~mode}
|
|
\newcommand{\fms}{\em failure~modes}
|
|
\newcommand{\dc}{\em derived~component}
|
|
\newcommand{\dcs}{\em derived~components}
|
|
\newcommand{\bc}{\em base~component}
|
|
\newcommand{\bcs}{\em base~components}
|
|
\newcommand{\irl}{in~real~life}
|
|
%\newcommand{\derivec}{\ensuremath{\mathcal{\bowtie}}}
|
|
\newcommand{\derivec}{\ensuremath{{D}}}
|
|
\newcommand{\ft}{\ensuremath{4\!\!\rightarrow\!\!20mA} }
|
|
\begin{document}
|
|
|
|
|
|
|
|
%\section{Applying failure Mode Modular de-Composition to integrated electronic and software Systems}
|
|
\begin{frame}
|
|
\frametitle{Failure Mode Modular De-Composition(FMMD)}
|
|
\begin{itemize}
|
|
\pause \item FMMD is a modularised variant of FMEA
|
|
\pause \item FMMD can model integrated mechanical, electrical and software systems.
|
|
\pause \item FMMD has efficiency benefits (pre analysed component re-use, over-all reduced complexity of checking) compared to traditional FMEA
|
|
\pause \item FMMD models can be used to assist in the production of traditional FMEA based
|
|
methodologies (PFMEA, FMECA, FMEDA FTA etc.)
|
|
\end{itemize}
|
|
%\tableofcontents[currentsection]
|
|
\end{frame}
|
|
|
|
|
|
|
|
\section{F.M.E.A.}
|
|
\begin{frame}
|
|
\frametitle{FMEA}
|
|
%\tableofcontents[currentsection]
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMEA}
|
|
We now talk about Failure Mode Effects Analysis, and the different ways it is applied.
|
|
%These techniques are discussed, and then
|
|
%a refinement(FMMD) is proposed, which is essentially a modularisation of the FMEA process.
|
|
%
|
|
|
|
\begin{itemize}
|
|
\pause \item Failure
|
|
\pause \item Mode
|
|
\pause \item Effects
|
|
\pause \item Analysis
|
|
\end{itemize}
|
|
|
|
\end{frame}
|
|
|
|
% % \begin{itemize}
|
|
% \item Failure
|
|
% \item Mode
|
|
% \item Effects
|
|
% \item Analysis
|
|
% \end{itemize}
|
|
|
|
|
|
\subsection{FMEA basic concept}
|
|
|
|
\begin{frame}
|
|
\begin{itemize}
|
|
\pause \item \textbf{F - Failures of given component} Consider a component in a system
|
|
\pause \item \textbf{M - Failure Mode} Look at one of the ways in which it can fail (i.e. determine a component `failure~mode')
|
|
\pause \item \textbf{E - Effects} Determine the effects this failure mode will cause to the system we are examining
|
|
\pause \item \textbf{A - Analysis} Analyse how much impact this symptom will have on the environment/people/the system itsself
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMEA Example: Milli-volt reader}
|
|
Example: Let us consider a system, in this case a milli-volt reader, consisting
|
|
of instrumentation amplifiers connected to a micro-processor
|
|
that reports its readings via RS-232.
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=175pt]{./mvamp.png}
|
|
% mvamp.png: 561x403 pixel, 72dpi, 19.79x14.22 cm, bb=0 0 561 403
|
|
\end{figure}
|
|
|
|
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMEA Example: Milli-volt reader}
|
|
Let us perform an FMEA and consider how one of its resistors failing could affect
|
|
it.
|
|
For the sake of example let us choose resistor R1 in the OP-AMP gain circuitry.
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=175pt]{./mvamp.png}
|
|
% mvamp.png: 561x403 pixel, 72dpi, 19.79x14.22 cm, bb=0 0 561 403
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
%
|
|
\frametitle{FMEA Example: Milli-volt reader}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=80pt]{./mvamp.png}
|
|
% mvamp.png: 561x403 pixel, 72dpi, 19.79x14.22 cm, bb=0 0 561 403
|
|
\end{figure}
|
|
\begin{itemize}
|
|
\pause \item \textbf{F - Failures of given component} The resistor (R1) could fail by going OPEN or SHORT (EN298 definition).
|
|
\pause \item \textbf{M - Failure Mode} Consider the component failure mode SHORT
|
|
\pause \item \textbf{E - Effects} This will drive the minus input LOW causing a HIGH OUTPUT/READING
|
|
\pause \item \textbf{A - Analysis} The reading will be out of normal range, and we will have an erroneous milli-volt reading
|
|
\end{itemize}
|
|
%
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{Four main Variants of FMEA}
|
|
\begin{itemize}
|
|
\pause \item \textbf{PFMEA - Production} \pause Car Manufacture etc
|
|
\pause \item \textbf{FMECA - Criticality} \pause Military/Space
|
|
\pause \item \textbf{FMEDA - Statistical safety} \pause EN61508/IOC1508 \pause Safety Integrity Levels
|
|
\pause \item \textbf{DFMEA - Design or static/theoretical} \pause EN298/EN230/UL1998
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\subsection{FMEA - General Criticism}
|
|
\begin{frame}
|
|
\frametitle{FMEA - General Criticism}
|
|
|
|
\begin{itemize}
|
|
\pause \item FMEA type methodologies were designed for simple electro-mechanical systems of the 1940's to 1960's.
|
|
\pause \item Reasoning Distance - component failure to system level symptom : \pause Software controlled systems have another layer of reasoning distance
|
|
\pause \item State explosion - impossible to perform rigorously
|
|
\pause \item Difficult to re-use previous analysis work
|
|
\pause \item Very Difficult to model simultaneous failures.
|
|
|
|
\end{itemize}
|
|
|
|
%
|
|
|
|
\end{frame}
|
|
|
|
|
|
\subsection{FMEA - Better Methodology - Wish List}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMEA - Better Metodology - Wish List}
|
|
|
|
\begin{itemize}
|
|
|
|
\pause \item State explosion
|
|
\pause \item Rigorous (total coverage)
|
|
\pause \item Reasoning Traceable \pause ideally across disciplines \pause Mechanical \pause Electrical \pause Software
|
|
\pause \item Re-usable
|
|
\pause \item Simultaneous failures
|
|
%\pause \item
|
|
\end{itemize}
|
|
|
|
%FMEDA is a modern extension of FMEA, in that it will allow for
|
|
%self checking features, and provides detailed recommendations for computer/software architecture,
|
|
%but
|
|
|
|
\end{frame}
|
|
\section{Failure Mode Modular De-Composition}
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
% Consider the FMEA type methodologies
|
|
% where we look at all the failure modes in a system, and then
|
|
% see how they can affect all other components within it,
|
|
% to determine its system level symptom or failure mode.
|
|
% We need to look at a large number of failure scenarios
|
|
% to do this completely (all failure modes against all components).
|
|
% This is represented in equation~\ref{eqn:fmea_state_exp},
|
|
% where $N$ is the total number of components in the system, and
|
|
% $f$ is the number of failure modes per component.
|
|
%
|
|
% \begin{equation}
|
|
% \label{eqn:fmea_state_exp}
|
|
% N.(N-1).f % \\
|
|
% %(N^2 - N).f
|
|
% \end{equation}
|
|
|
|
\begin{itemize}
|
|
|
|
\pause \item Analysis occurs in small stages, within {\fgs}
|
|
\pause \item Each {\fg} is analysed until we have a set of its symptoms of failure.
|
|
\pause \item A {\dc} is created with its failure modes being the symptoms from the {\fg}
|
|
\pause \item We can now use {\dcs} as higher level components
|
|
\pause \item We can build a failure model hierarchy in this way
|
|
%\pause \item
|
|
\end{itemize}
|
|
|
|
% The FMMD methodology breaks the analysis down into small stages,
|
|
% by making the analyst choose {\fgs} of components, to which FMEA is applied.
|
|
% When analysed, a set of symptoms of failure for the {\fg} is used to create a derived~component. \pause
|
|
% The derived components failure modes, are the symptoms of the {\fg}
|
|
% from which it was derived. \pause
|
|
% We can use derived components to form `higher~level' {\fgs}.
|
|
% This creates an analysis hierarchy.
|
|
\end{frame}
|
|
|
|
|
|
\subsection{FMMD Outline of Methodology}
|
|
\begin{frame}
|
|
\frametitle{FMMD - Outline of Methodology}
|
|
\begin{itemize}
|
|
\pause \item Select `{\fgs}' of components ( groups that perform a well defined function).
|
|
\pause \item Using the failure modes of the components create failure scenarios.
|
|
\pause \item Analyse each failure scenario of the {\fg}.
|
|
\pause \item Collect Symptoms.
|
|
\pause \item Create a '{\dc}', where its failure modes are the symptoms of the {\fg} from which it was derived.
|
|
\pause \item The {\dc} is now available to be used in higher level {\fgs}.
|
|
%\pause \item We can represent this process as a function which converts a {\fg} into a {\dc} and use the symbol $ \derivec $ to represet it.
|
|
\pause $ \derivec ( FunctionalGroup ) \rightarrow {DerivedComponent} $
|
|
%\item could use AMALG instead here $ \amalg $
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\subsection{FMMD - Example - Milli Volt Amplifier}
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Milli Volt Amplifier}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=100pt]{./mvampcircuit.png}
|
|
% mvampcircuit.png: 243x143 pixel, 72dpi, 8.57x5.04 cm, bb=0 0 243 143
|
|
\end{figure}
|
|
|
|
We return to the milli-volt amplifier as an example to analyse.
|
|
\pause
|
|
We can begin by looking for functional groups.\pause
|
|
The resistors perform a fairly common function in electronics, that of the potential divider.
|
|
So our first functional group is $\{ R1, R2 \}$.\pause
|
|
We can now take the failure modes for the resistors (OPEN and SHORT EN298) and see what effect each of these failures will have on the {\fg} (the potential divider).
|
|
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Resistor and failure modes}
|
|
Resistor and its failure modes represented as a directed graph.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=200pt]{./resistor_failure_graph.png}
|
|
% resistor_failure_graph.png: 391x279 pixel, 93dpi, 10.68x7.62 cm, bb=0 0 303 216
|
|
\label{fig:resasfm}
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
\subsubsection{Potential Divider}
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Failure mode analysis of Potential Divider}
|
|
|
|
|
|
\begin{table}
|
|
\begin{tabular}{|| l | l | c | c | l ||} \hline
|
|
\textbf{Failure Scenario} & & \textbf{Pot Div Effect} & & \textbf{Symptom} \\
|
|
\textbf{ / test case } & & \textbf{ } & & \textbf{ } \\
|
|
\hline
|
|
FS1: R1 SHORT & & $LOW$ & & $PDLow$ \\ \hline
|
|
FS2: R1 OPEN & & $HIGH$ & & $PDHigh$ \\ \hline
|
|
FS3: R2 SHORT & & $HIGH$ & & $PDHigh$ \\ \hline
|
|
FS4: R2 OPEN & & $LOW$ & & $PDLow$ \\ \hline
|
|
\hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=100pt,keepaspectratio=true]{./pd.png}
|
|
% pd.png: 361x241 pixel, 72dpi, 12.74x8.50 cm, bb=0 0 361 241
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Potential Divider as Derived Component}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=175pt]{./pd_failures_as_graph.png}
|
|
% pd_dc_failures_as_graph.png: 389x284 pixel, 93dpi, 10.63x7.76 cm, bb=0 0 301 220
|
|
\label{fig:pd}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Potential Divider as Derived Component}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=200pt]{./pd_dc_failures_as_graph.png}
|
|
% pd_dc_failures_as_graph.png: 389x284 pixel, 93dpi, 10.63x7.76 cm, bb=0 0 301 220
|
|
\label{fig:pd}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Potential Divider as Derived Component}
|
|
|
|
We can now use this pre-analysed potential divider `derived~component'
|
|
in a higher level design.
|
|
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=100pt]{./pd_dc_failures_as_graph.png}
|
|
% pd_dc_failures_as_graph.png: 389x284 pixel, 93dpi, 10.63x7.76 cm, bb=0 0 301 220
|
|
\label{fig:pd}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
\subsection{Non Inverting OP-AMP}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Non Inverting OP-AMP}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics{./mvampcircuit.png}
|
|
% mvampcircuit.png: 243x143 pixel, 72dpi, 8.57x5.04 cm, bb=0 0 243 143
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Non Inverting OP-AMP}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=300pt]{./non_inv_amp_fmea.png}
|
|
% non_inv_amp_fmea.png: 964x492 pixel, 96dpi, 25.50x13.02 cm, bb=0 0 723 369
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Non Inverting OP-AMP}
|
|
% \begin{figure}
|
|
% \centering
|
|
% \includegraphics[width=200pt]{./opamp_failures_as_graph.png} // op amp failure modes
|
|
% % opamp_failures_as_graph.png: 329x440 pixel, 93dpi, 8.99x12.02 cm, bb=0 0 255 341
|
|
% \end{figure}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=150pt]{./fg_opamp_pd_as_graph.png}
|
|
% fg_opamp_pd_as_graph.png: 750x826 pixel, 93dpi, 20.49x22.56 cm, bb=0 0 581 640
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Non Inverting OP-AMP}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=150pt]{./n_inv_dc.png}
|
|
% n_inv_dc.png: 296x326 pixel, 72dpi, 10.44x11.50 cm, bb=0 0 296 326
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example - Non Inverting OP-AMP}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=200pt]{./fmmd_exm_h.png}
|
|
% fmmd_exm_h.png: 376x241 pixel, 72dpi, 13.26x8.50 cm, bb=0 0 376 241
|
|
\end{figure}
|
|
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
%We can view the functional groups in FMMD as forming a hierarchy.
|
|
%If
|
|
% For the sake of example we consider each functional group to
|
|
% be three components, the figure below shows
|
|
% how the levels work and converge to a top or system level.
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=300pt]{./three_tree.png}
|
|
% three_tree.png: 780x226 pixel, 72dpi, 27.52x7.97 cm, bb=0 0 780 226
|
|
\caption{Functional Group Tree example}
|
|
\label{fig:three_tree}
|
|
\end{figure}
|
|
\pause
|
|
For the sake of example we consider each functional group to
|
|
be three components, the figure below shows
|
|
how the levels work and converge to a top or system level.
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
The fact FMMD analyses small groups of components at a time, and organises them
|
|
into a hierarchy
|
|
addresses the state explosion problem. \pause
|
|
|
|
For FMEA where we check every component failure mode rigorously
|
|
against all the other components (we could call this \textbf{RFMEA})
|
|
Where $N$ is the number of components, we can determine the order
|
|
of complexity $ O(N^2) $ thus.
|
|
% %
|
|
\begin{equation}
|
|
\label{eqn:fmea_single2}
|
|
N.(N-1).f
|
|
\end{equation}
|
|
%
|
|
% %\end{frame}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - comparing number of checks RFMEA $\ldots$ FMMD}
|
|
|
|
If we consider $c$ to be the number of components in a {\fg}, $f$ is the number of failure modes per component, and
|
|
$L$ to be the number of levels in the hierarchy of FMMD analysis.
|
|
|
|
|
|
We can represent the number of failure scenarios to check in an FMMD hierarchy
|
|
with equation~\ref{eqn:anscen}.
|
|
\pause
|
|
\begin{equation}
|
|
\label{eqn:anscen}
|
|
\sum_{n=0}^{L} {c}^{n}.c.f.(c-1)
|
|
\end{equation}
|
|
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
% So for a very simple analysis with three components forming a functional group where
|
|
% each component has three failure modes, we have only one level (zero'th).
|
|
% So to check every failure modes against the other components in the functional group
|
|
% requires 18 checks.
|
|
%
|
|
% \begin{equation}
|
|
% \label{eqn:anscen2}
|
|
% \sum_{n=0}^{0} {3}^{0}.3.3.(3-1) = 18
|
|
% \end{equation}
|
|
% \clearpage
|
|
%
|
|
%
|
|
%
|
|
% In other words, we have three components in our functional group,
|
|
% and nine failure modes to consider.
|
|
% So taking each failure mode and looking at how that could affect the functional group,
|
|
% we must compare each failure mode against the two other components (the `$c-1$' term).
|
|
%
|
|
% For the one `zero' level FMMD case we are doing the same thing as FMEA type analysis
|
|
% (but on a very simple small sub-system).
|
|
% We are looking at how each failure~mode can effect the system/top level.
|
|
% We can use equation~\ref{eqn:fmea_state_exp44} to represent
|
|
% the number of checks to rigorously perform FMEA, where $N$ is the total
|
|
% number of components in the system, and $f$ is the number of failures per component.
|
|
|
|
|
|
%
|
|
% Where $N=3$ and $f=3$ we can see that the number of checks for this simple functional
|
|
% group is the same for equation~\ref{eqn:fmea_state_exp22}
|
|
% and equation~\ref{eqn:anscen}.
|
|
% \clearpage
|
|
|
|
%\section{Example}/derivec
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
To see the effects of reducing `state~explosion' we can use an example.
|
|
% with fixed numbers
|
|
%for components in a functional group, and failure modes per component.
|
|
Let us take a system with 3 levels of FMMD analysis,
|
|
with three components per functional group and three failure modes per component,
|
|
and apply these formulae.
|
|
Having 4 levels (in addition to the top zeroth level)
|
|
will require 81 base level components.
|
|
|
|
$$
|
|
%\begin{equation}
|
|
\label{eqn:fmea_state_exp22}
|
|
81.(81-1).3 = 19440 % \\
|
|
%(N^2 - N).f
|
|
%\end{equation}
|
|
$$
|
|
|
|
$$
|
|
%\begin{equation}
|
|
% \label{eqn:anscen}
|
|
\sum_{n=0}^{3} {3}^{n}.3.3.(2) = 720
|
|
%\end{equation}
|
|
$$
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
|
|
|
|
|
|
\begin{itemize}
|
|
\pause \item Thus for FMMD we needed to examine 720 failure~modes against functionally adjacent components, and for traditional FMEA
|
|
type analysis methods, the number rises to 19440.
|
|
\pause \item 19440 `checks' is not practical
|
|
\pause \item 720 checks is quite alot, but...
|
|
\pause \item Modules in FMMD can be re-used...
|
|
\end{itemize}
|
|
% In practical example followed through, no more than 9 components have ever been required for a functional
|
|
% group and the largest known number of failure modes has been 6.
|
|
% If we take these numbers and double them (18 components per functional group
|
|
% and 12 failure modes per component) and apply the formulas for a 4 level analysis
|
|
% (i.e.
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
|
|
To determine all possible double simultaneous failures for rigorous FMEA
|
|
the order $O(N^3)$.
|
|
|
|
|
|
\begin{equation}
|
|
\label{eqn:fmea_state_exp2}
|
|
N.(N-1).(N-2).f % \\
|
|
%(N^2 - N).f
|
|
\end{equation}
|
|
|
|
Or express in terms of the level
|
|
|
|
\begin{equation}
|
|
\label{eqn:fmea_state_exp2}
|
|
c^{L+1}.(c^{L+1}-1).(c^{L+1}-2).f % \\
|
|
%(N^2 - N).f
|
|
\end{equation}
|
|
|
|
\pause
|
|
The FMMD case (equation~\ref{eqn:anscen2}), is cubic within the functional groups only,
|
|
not all the components in the system.
|
|
\begin{equation}
|
|
\label{eqn:anscen2}
|
|
\sum_{n=0}^{L} {c}^{n}.c.f.(c-1).(c-2)
|
|
\end{equation}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
\textbf{Traceability}
|
|
Because each reasoning stage contains associations ($FailureMode \rightarrow Symptom$)
|
|
we can trace the `reasoning' from base level component failure mode to top level/system
|
|
failure, by traversing the tree/hierarchy. This is in effect providing a `framework' of the reasoning.
|
|
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
\textbf{Re-usability}
|
|
Electronic Systems use commonly re-used functional groups (such as potential~dividers, amplifier configurations etc)
|
|
Once a derived component is determined, it can generally be used in other projects.
|
|
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
\textbf{Total coverage}
|
|
With FMMD we can ensure that all component failure modes
|
|
have been represented as a symptom in the derived components created from them.
|
|
We can thus apply automated checking to ensure that no
|
|
failure modes, from base or derived components have been
|
|
missed in an analysis.
|
|
\end{frame}
|
|
|
|
|
|
|
|
\subsection{FMMD summary}
|
|
\begin{frame}
|
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
|
\textbf{Conclusion: FMMD}
|
|
|
|
\begin{itemize}
|
|
\pause \item Addresses State Explosion (single and multiple failure models)
|
|
\pause \item Addresses total coverage of all components and their failure modes
|
|
\pause \item Provides traceable reasoning
|
|
\pause \item derived components are re-use-able
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
\section{Software and Failure Mode Effects Analysis}
|
|
|
|
\subsection{Software and FMEA---Current work}
|
|
\begin{frame}
|
|
\frametitle{Software FMEA (SFMEA) --- Current work }
|
|
%\paragraph{Current work on Software FMEA}
|
|
\begin{itemize}
|
|
\pause \item SFMEA is performed in isolation to hardware FMEA
|
|
\pause \item SFMEA maps variable corruption for {\fms} ---
|
|
\pause this means a large number of combinations --- \pause automated SFMEA
|
|
\pause databases
|
|
tracking the relationships between variable corruption
|
|
and system failure modes
|
|
%\pause \item %Because of the large number of combinations for considering all variables as corruptible
|
|
% automated SFMEA
|
|
|
|
\pause \item Some schools of thought recommend combining SFTA with SFMEA
|
|
\pause \item FMMD is different, allows integrated hardware and software models
|
|
\end{itemize}
|
|
% SFMEA usually does not seek to integrate
|
|
% hardware and software models, but to perform
|
|
% FMEA on the software in isolation~\cite{procsfmea}.
|
|
% %
|
|
% Work has been performed using databases
|
|
% to track the relationships between variables
|
|
% and system failure modes~\cite{procsfmeadb}, to %work has been performed to
|
|
% introduce automation into the FMEA process~\cite{appswfmea} and to provide code analysis
|
|
% automation~\cite{modelsfmea}. Although the SFMEA and hardware FMEAs are performed separately,
|
|
% some schools of thought aim for Fault Tree Analysis (FTA)~\cite{nasafta,nucfta} (top down - deductive)
|
|
% and FMEA (bottom-up inductive)
|
|
% to be performed on the same system to provide insight into the
|
|
% software hardware/interface~\cite{embedsfmea}.
|
|
% %
|
|
% Although this
|
|
% would give a better picture of the failure mode behaviour, it
|
|
% is by no means a rigorous approach to tracing errors that may occur in hardware
|
|
% through to the top (and therefore ultimately controlling) layer of software.
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Software and FMMD}
|
|
\begin{frame}
|
|
\frametitle{FMMD - How to apply this to software}
|
|
Clearly we need to be able to represent software failure modes
|
|
in a clear and modular model.
|
|
\pause
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100pt]{./contract_function.png}
|
|
% contract_function.png: 181x256 pixel, 72dpi, 6.39x9.03 cm, bb=0 0 181 256
|
|
\caption{Design by Contract Programmatic Function}
|
|
\label{fig:dbcpf}
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - How to apply this to software}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=35pt]{./contract_function.png}
|
|
% contract_function.png: 181x256 pixel, 72dpi, 6.39x9.03 cm, bb=0 0 181 256
|
|
\caption{Design by Contract Programmatic Function}
|
|
\label{fig:dbcpf}
|
|
\end{figure}
|
|
\begin{itemize}
|
|
\pause \item Software is already modular call tree, function hierarchy \pause A function can be considered as a {\fg}
|
|
\pause \item A function has inputs and outputs, and a task to perform
|
|
\pause \item contract programming \pause , giving a function invariants, pre and post conditions
|
|
\end{itemize}
|
|
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - How to apply this to software}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=35pt]{./contract_function.png}
|
|
% contract_function.png: 181x256 pixel, 72dpi, 6.39x9.03 cm, bb=0 0 181 256
|
|
\caption{Design by Contract Programmatic Function}
|
|
\label{fig:dbcpf}
|
|
\end{figure}
|
|
\begin{itemize}
|
|
\pause \item Pre condition violations are analogous to component failure modes
|
|
\pause \item Post condition violations are analogous to symptoms of failure of the function \pause i.e. the derived component failure modes
|
|
\end{itemize}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
|
|
|
|
For the purpose of example, we chose a simple common safety critical industrial circuit
|
|
that is nearly always used in conjunction with a programmatic element.
|
|
A common method for delivering a quantitative value in analogue electronics is
|
|
to supply a current signal to represent the value to be sent. %~\cite{aoe}[p.934].
|
|
Usually, $4mA$ represents a zero or starting value and $20mA$ represents the full scale,
|
|
and this is referred to as {\ft} signalling.
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=200pt]{./ftcontext.png}
|
|
% ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385
|
|
\caption{Context Diagram for {\ft} loop}
|
|
\label{fig:ftcontext}
|
|
\end{figure}
|
|
%The diagram in figure~\ref{fig:ftcontext} shows some equipment which is sending a {\ft}
|
|
%signal to a micro-controller system.
|
|
%The signal is locally driven over a load resistor, and then read into the micro-controller via
|
|
%an ADC and its multiplexer.
|
|
%With the voltage detected at the ADC the multiplexer can read the intended quantitative
|
|
%value from the external equipment.
|
|
\end{frame}
|
|
%
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
General Failure behaviour of {\ft} signalling
|
|
\begin{itemize}
|
|
\pause \item Electrical Current in a loop is constant (Kirchoff)
|
|
\pause \item Current to voltage conversion is simple at receiving end \pause a single resistor
|
|
\pause \item Detectable Error if outside 4mA 20mA range
|
|
\pause \item On disconnection \pause : 0mA, on mis-wiring\pause : 0mA
|
|
%\pause \item Post condition violations are analogous to symptoms of failure of the function
|
|
\end{itemize}
|
|
%{\ft} has an electrical advantage as well because the current in a loop is constant. %~\cite{aoe}[p.20].
|
|
%Thus resistance in the wires between the source and the receiving end is not an issue
|
|
%that can alter the accuracy of the signal.
|
|
%
|
|
% This circuit has many advantages for safety. If the signal becomes disconnected
|
|
% it reads an out of range $0mA$ at the receiving end. This is outside the {\ft} range,
|
|
% and is therefore easy to detect as an error rather than an incorrect value.
|
|
%
|
|
% General Failure behaviour of {\ft}.
|
|
%
|
|
% Should the driving electronics go wrong at the source end, it will usually
|
|
% supply far too little or far too much current, making an error condition easy to detect.
|
|
% %
|
|
% At the receiving end, one needs a resistor to convert the
|
|
% current signal into a voltage that we can read with an ADC.%
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
If we consider the software at the top of the failure mode hierarchy
|
|
the hardware is at the bottom.
|
|
\pause
|
|
Yourdon, afferent---transform---efferent data flow, in an embedded system our
|
|
sensors---data processing/software---actuators.
|
|
\pause
|
|
So the electronics are the below software in a modular hierarchy....
|
|
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
|
|
\subsection{Example Electrical and Software system FMMD Analysis}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=150pt]{./ftcontext.png}
|
|
% ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385
|
|
\caption{Context Diagram for {\ft} loop}
|
|
\label{fig:ftcontext}
|
|
\end{figure}
|
|
\pause
|
|
Starting with the bottom-up for this {\ft} input, we have the resistor and the ADC.
|
|
The resistor converts current to voltage and the ADC allows us to read the voltage.
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100pt]{./ftcontext.png}
|
|
% ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385
|
|
\caption{Context Diagram for {\ft} loop}
|
|
\label{fig:ftcontext}
|
|
\end{figure}
|
|
\pause
|
|
Bottom level {\fg}:
|
|
$G_1 = \{ R, ADC \},$
|
|
\pause
|
|
$ fm(R) = \{ OPEN, SHORT \},$
|
|
\pause
|
|
$ fm(ADC) = \{ ADC_{STUCKAT} , ADC_{MUXFAIL} , ADC_{LOW} , ADC_{HIGH} \} .$
|
|
\end{frame}
|
|
%\subsection{Example Electrical and Software system FMMD Analysis}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
% \begin{figure}[h]
|
|
% \centering
|
|
% \includegraphics[width=100pt]{./ftcontext.png}
|
|
% % ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385
|
|
% \caption{Context Diagram for {\ft} loop}
|
|
% \label{fig:ftcontext}
|
|
% \end{figure}
|
|
% \pause
|
|
{ \tiny
|
|
\begin{table}[h+]
|
|
\caption{$G_1$: Failure Mode Effects Analysis: Convert mA to Voltage (CMATV)} % title of Table
|
|
\label{tbl:cmatv}
|
|
|
|
\begin{tabular}{|| l | c | l ||} \hline
|
|
\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
|
|
\textbf{Scenario} & \textbf{effect} & \textbf{ADC } \\ \hline
|
|
\hline
|
|
1: $R_{OPEN}$ & resistor open, & $HIGH$ \\
|
|
& voltage on pin high & \\ \hline
|
|
|
|
2: $R_{SHORT}$ & resistor shorted, & $LOW$ \\
|
|
& voltage on pin low & \\ \hline
|
|
|
|
|
|
3: $ADC_{STUCKAT}$ & ADC reads out & $V\_ERR$ \\
|
|
& fixed value & \\ \hline
|
|
|
|
|
|
|
|
4: $ADC_{MUXFAIL}$ & ADC may read & $V\_ERR$ \\
|
|
& wrong channel & \\ \hline
|
|
|
|
5: $ADC_{LOW}$ & output low & $LOW$ \\
|
|
6: $ADC_{HIGH}$ & output high & $HIGH$ \\ \hline
|
|
|
|
|
|
\hline
|
|
|
|
|
|
\hline
|
|
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
\pause
|
|
We can express this using the `$\derivec$' function thus:
|
|
$ CMATV = \; \derivec (G_1) .$ As its failure modes are the symptoms of failure from the functional group we can now state:
|
|
$fm ( CMATV ) = \{ HIGH , LOW, V\_ERR \} .$
|
|
}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100pt]{./ftcontext.png}
|
|
% ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385
|
|
\caption{Context Diagram for {\ft} loop}
|
|
\label{fig:ftcontext}
|
|
\end{figure}
|
|
\pause
|
|
We have analysed the hardware for our {\ft} input.
|
|
\pause
|
|
We must now look at the software.
|
|
|
|
\end{frame}
|
|
|
|
\subsection{Software {\ft} input}
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100pt]{./ftcontext.png}
|
|
% ftcontext.png: 767x385 pixel, 72dpi, 27.06x13.58 cm, bb=0 0 767 385
|
|
\caption{Context Diagram for {\ft} loop}
|
|
\label{fig:ftcontext}
|
|
\end{figure}
|
|
We consider two software functions, $Read\_ADC()$ which returns a value from the ADC, which is called by
|
|
$ Read\_4\_20\_input() .$ which returns a pro-mil value for the input. \pause
|
|
As $Read\_ADC$ is the function called it is lower in the call tree hierarchy. \pause
|
|
We form a {\fg} with $CMATV$ and this software function.
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=140pt]{./read_adc.jpg}
|
|
% read_adc.jpg: 452x514 pixel, 96dpi, 11.96x13.60 cm, bb=0 0 339 386
|
|
\caption{Software Function: \textbf{read\_ADC}}
|
|
\label{fig:read_ADC()}
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=32pt]{./read_adc.jpg}
|
|
% read_adc.jpg: 452x514 pixel, 96dpi, 11.96x13.60 cm, bb=0 0 339 386
|
|
\caption{Software Function: \textbf{read\_ADC}}
|
|
\label{fig:read_ADC()}
|
|
\end{figure}
|
|
|
|
\begin{itemize}
|
|
\pause \item validate mux channel number
|
|
\pause \item Set MUX
|
|
\pause \item initiate ADC read
|
|
\pause \item read value
|
|
\pause \item return value to calling function
|
|
\end{itemize}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- {\ft} input}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=32pt]{./read_adc.jpg}
|
|
% read_adc.jpg: 452x514 pixel, 96dpi, 11.96x13.60 cm, bb=0 0 339 386
|
|
\caption{Software Function: \textbf{read\_ADC}}
|
|
\label{fig:read_ADC()}
|
|
\end{figure}
|
|
|
|
Pre-conditions
|
|
\begin{itemize}
|
|
\pause \item MUX channel number in range
|
|
\pause \item No timeout on ADC read
|
|
\pause \item ADC Vref out of range
|
|
\end{itemize}
|
|
Post-conditions
|
|
\begin{itemize}
|
|
\pause \item in range (0...1023) value from ADC/MUX returned
|
|
\end{itemize}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- RADC function}
|
|
Treating the read\_ADC() function as a {\fg}.
|
|
|
|
The pre-conditions that can be violated are ADC\_TIMEOUT, MUX\_CHAN, ADC\_VREF.
|
|
We could term the failure modes of this function as
|
|
\{ ADC\_TIMEOUT\_OCCURS, INCORRECT\_MUX\_CHAN, INCORRECT\_VREF \}
|
|
\pause
|
|
\\
|
|
We now create a {\fg} called RADC consisting of read\_ADC() and the hardware it interface directly with: CMATV.
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{FMMD - Example integrated hardware/software system --- RADC function}
|
|
{
|
|
\tiny
|
|
\begin{table}[h+]
|
|
\caption{$G_2$: Failure Mode Effects Analysis: Read\_ADC (RADC) and CMATV} % title of Table
|
|
\label{tbl:radc}
|
|
\begin{tabular}{|| l | c | l ||} \hline
|
|
\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
|
|
\textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
|
|
\hline
|
|
1: ${INCORRECT\_MUX\_CHAN}$ & wrong voltage & $VV\_ERR$ \\
|
|
& read & \\ \hline
|
|
|
|
2: ${INCORRECT_VREF}$ & ADC volt-ref & $VV\_ERR$ \\
|
|
& incorrect & \\ \hline
|
|
|
|
|
|
3: ${ADC\_TIMEOUT\_OCCURS}$ & ADC volt-ref & $VV\_ERR$ \\
|
|
& incorrect & \\ \hline
|
|
|
|
|
|
4: $CMATV_{V\_ERR}$ & voltage value & $VV\_ERR$ \\
|
|
& incorrect & \\ \hline
|
|
|
|
|
|
|
|
5: $CMATV_{HIGH}$ & ADC reads & $HIGH$ \\
|
|
& high voltage & \\ \hline
|
|
|
|
6: $CMATV_{HIGH}$ & ADC reads & $LOW$ \\
|
|
& low voltage & \\ \hline
|
|
\hline
|
|
\hline
|
|
\end{tabular}
|
|
\end{table}
|
|
|
|
|
|
}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
Collecting symptoms, we can now create a {\dc} RADC, with the following failure modes: $ fm(RADC) = \{ VV\_ERR, HIGH, LOW \} .$
|
|
\pause
|
|
We now have a model in which we have electronic and software
|
|
modules represented.
|
|
|
|
\pause
|
|
|
|
We can now look at the second software function.
|
|
\end{frame}
|
|
|
|
%
|
|
|
|
% \begin{frame}
|
|
% \frametitle{FMMD - Example integrated hardware/software system --- read\_4\_20_input}
|
|
% % \begin{figure}[h]
|
|
% \centering
|
|
% \includegraphics[width=120pt]{./read_4_20_input.jpg}
|
|
% % read_adc.jpg: 452x514 pixel, 96dpi, 11.96x13.60 cm, bb=0 0 339 386
|
|
% \caption{Software Function: \textbf{read\_4\_20_input()}}
|
|
% \label{fig:read_4_20_input}
|
|
% \end{figure}
|
|
%end{frame}
|
|
|
|
\begin{frame}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=200pt]{./read_4_20_input.jpg}
|
|
% read_4_20_input.jpg: 452x514 pixel, 96dpi, 11.96x13.60 cm, bb=0 0 339 386
|
|
\caption{Read 4 to 20mA input function}
|
|
\label{fig:read_4_20_input}
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=60pt]{./read_4_20_input.jpg}
|
|
% read_4_20_input.jpg: 452x514 pixel, 96dpi, 11.96x13.60 cm, bb=0 0 339 386
|
|
\caption{Read 4 to 20mA input function}
|
|
\label{fig:read_4_20_input}
|
|
\end{figure}
|
|
|
|
This function has one pre-condition, the voltage range ($0.88V \leftrightarrow 4.4V$)
|
|
and one postcondition {\ft} current mapped to per-mil integer output.
|
|
\pause
|
|
We could term the failure mode of this function, voltage out of range, as
|
|
\{ VRNGE \}.
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
|
|
{
|
|
\tiny
|
|
\begin{table}[h+]
|
|
\caption{$G_3$: Read\_4\_20: Failure Mode Effects Analysis} % title of Table
|
|
\label{tbl:r420i}
|
|
|
|
\begin{tabular}{|| l | c | l ||} \hline
|
|
\textbf{Failure} & \textbf{failure} & \textbf{Symptom} \\
|
|
\textbf{Scenario} & \textbf{effect} & \textbf{RADC } \\ \hline
|
|
\hline
|
|
1: $RI_{VRGE}$ & voltage & $OUT\_OF\_$ \\
|
|
& outside range & $RANGE$ \\ \hline
|
|
|
|
2: $RADC_{VV\_ERR}$ & voltage & $VAL\_ERR$ \\
|
|
& incorrect & \\ \hline
|
|
|
|
|
|
3: $RADC_{HIGH}$ & voltage value & $VAL\_ERR$ \\
|
|
& incorrect & \\ \hline
|
|
|
|
|
|
|
|
4: $RADC_{LOW}$ & ADC may read & $OUT\_OF\_$ \\
|
|
& wrong channel & $RANGE$ \\ \hline
|
|
\hline
|
|
\end{tabular}
|
|
\end{table}
|
|
}
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
We can finally make a {\dc} to represent a failure mode model for our function $read\_4\_20\_input$ (R420I) thus:
|
|
%
|
|
$ R420I = \; \derivec(G_3) .$
|
|
%
|
|
This new {\dc} has the following {\fms}:
|
|
$$fm(R420I) = \{OUT\_OF\_RANGE, VAL\_ERR\} .$$
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=150pt,keepaspectratio=true]{./hd.png}
|
|
% hd.png: 416x381 pixel, 72dpi, 14.68x13.44 cm, bb=0 0 416 381
|
|
\caption{FMMD Hierarchy for {\ft} input}
|
|
\label{fig:hd}
|
|
\end{figure}
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
|
|
%\section{Conclusion}
|
|
%
|
|
\begin{itemize}
|
|
\item FMMD models integrated mechanical/electrical/software systems
|
|
\pause \item Each {\fg} to {\dc} transition represents a documented
|
|
reasoning stage.
|
|
\pause \item Unlike SFMEA software failure modes naturally link with hardware failure modes
|
|
\pause \item Added efficiency benefits\pause---smaller reasoning distances\pause---less checking for RFMEA
|
|
\pause \item Additionally, using FMMD we can determine a failure model for the hardware/software interface.%~\cite{sfmeainterface}.
|
|
\end{itemize}
|
|
\end{frame}
|
|
\begin{frame}
|
|
|
|
Questions ?
|
|
%The FMMD method has been demonstrated using the industry standard {\ft}
|
|
%input circuit and software.
|
|
%
|
|
% \pause
|
|
% The {\dc} representing the {\ft} reader
|
|
% shows that by taking a modular approach for FMEA, i.e. FMMD, we can integrate
|
|
% software and electro-mechanical models.
|
|
% %
|
|
% \pause
|
|
% With this analysis
|
|
% we have stages along the `reasoning~path' linking the failure modes from the
|
|
% electronics to those in the software.
|
|
% Each {\fg} to {\dc} transition represents a
|
|
% reasoning stage.
|
|
% %
|
|
% \pause
|
|
% With traditional FMEA methods the reasoning~distance is large, because
|
|
% it stretches from the component failure mode to the top---or---system level failure.
|
|
% %For this reason applying traditional FMEA to software stretches
|
|
% %the reasoning distance even further.
|
|
% %
|
|
% We now have a {\dc} for a {\ft} input. % in software.
|
|
% Typically, more than one such input could be present in a real-world system: we can thus
|
|
% %Not only have we integrated electronics and software in an FMEA, we can also
|
|
% re-use this analysis for each {\ft} input in the system.
|
|
% \pause
|
|
% %
|
|
% %The unsolved symptoms, or unobservable errors, i.e. $VAL\_ERR$ could be addressed
|
|
% %by another software function to read other known signals
|
|
% %via the MUX (i.e. voltage references). This strategy would
|
|
% %detect ADC\_STUCK\_AT and MUX\_FAIL failure modes.
|
|
%
|
|
%Detailing this however, is beyond the scope %and page-count
|
|
%of this paper.
|
|
%
|
|
%A software specification for a hardware interface will concentrate on
|
|
%how to interpret raw readings, or what signals to apply for actuators.
|
|
%Additionally, using FMMD we can determine a failure model for the hardware/software interface~\cite{sfmeainterface}. % interface as well.
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
Addendum --- Types of FMEA.
|
|
\end{frame}
|
|
|
|
\subsection{PFMEA - Production FMEA : 1940's to present}
|
|
|
|
\begin{frame}
|
|
\frametitle{PFMEA}
|
|
Production FMEA (or PFMEA), is FMEA used to prioritise, in terms of
|
|
cost, problems to be addressed in product production.\pause
|
|
|
|
It focuses on known problems, determines the
|
|
frequency they occur and their cost to fix.\pause
|
|
This is multiplied together and called an RPN
|
|
number.\pause
|
|
Fixing problems with the highest RPN number
|
|
will return most cost benefit.\pause
|
|
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
% benign example of PFMEA in CARS - make something up.
|
|
\frametitle{PFMEA Example}
|
|
|
|
{
|
|
\begin{table}[ht]
|
|
\caption{FMEA Calculations} % title of Table
|
|
%\centering % used for centering table
|
|
\begin{tabular}{|| l | l | c | c | l ||} \hline
|
|
\textbf{Failure Mode} & \textbf{P} & \textbf{Cost} & \textbf{Symptom} & \textbf{RPN} \\ \hline \hline
|
|
relay 1 n/c & $1*10^{-5}$ & 38.0 & indicators fail & 0.00038 \\ \hline
|
|
relay 2 n/c & $1*10^{-5}$ & 98.0 & doorlocks fail & 0.00098 \\ \hline
|
|
% rear end crash & $14.4*10^{-6}$ & 267,700 & fatal fire & 3.855 \\
|
|
% ruptured f.tank & & & & \\ \hline
|
|
|
|
|
|
\hline
|
|
\end{tabular}
|
|
\end{table}
|
|
}
|
|
|
|
%Savings: 180 burn deaths, 180 serious burn injuries, 2,100 burned vehicles. Unit Cost: $200,000 per death, $67,000 per injury, $700 per vehicle.
|
|
%Total Benefit: 180 X ($200,000) + 180 X ($67,000) + $2,100 X ($700) = $49.5 million.
|
|
%COSTS
|
|
%Sales: 11 million cars, 1.5 million light trucks.
|
|
%Unit Cost: $11 per car, $11 per truck.
|
|
%Total Cost: 11,000,000 X ($11) + 1,500,000 X ($11) = $137 million.
|
|
|
|
|
|
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
%\subsection{Production FMEA : Example Ford Pinto : 1975}
|
|
\begin{frame}
|
|
\frametitle{PFMEA Example: Ford Pinto: 1975}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=200pt]{./ad_ford_pinto_mpg_red_3_1975.jpg}
|
|
% ad_ford_pinto_mpg_red_3_1975.jpg: 720x933 pixel, 96dpi, 19.05x24.69 cm, bb=0 0 540 700
|
|
\caption{Ford Pinto Advert}
|
|
\label{fig:fordpintoad}
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{PFMEA Example: Ford Pinto: 1975}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=200pt]{./burntoutpinto.png}
|
|
% burntoutpinto.png: 376x250 pixel, 72dpi, 13.26x8.82 cm, bb=0 0 376 250
|
|
\caption{Burnt Out Pinto}
|
|
\label{fig:burntoutpinto}
|
|
\end{figure}
|
|
|
|
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{PFMEA Example: Ford Pinto: 1975}
|
|
{
|
|
\begin{table}[ht]
|
|
\caption{FMEA Calculations} % title of Table
|
|
%\centering % used for centering table
|
|
\begin{tabular}{|| l | l | c | c | l ||} \hline
|
|
\textbf{Failure Mode} & \textbf{P} & \textbf{Cost} & \textbf{Symptom} & \textbf{RPN} \\ \hline \hline
|
|
relay 1 n/c & $1*10^{-5}$ & 38.0 & indicators fail & 0.00038 \\ \hline
|
|
relay 2 n/c & $1*10^{-5}$ & 98.0 & doorlocks fail & 0.00098 \\ \hline
|
|
rear end crash & $14.4*10^{-6}$ & 267,700 & fatal fire & 3.855 \\
|
|
ruptured f.tank & & & allow & \\ \hline
|
|
|
|
rear end crash & $1$ & $11$ & recall & 11.0 \\
|
|
ruptured f.tank & & & fix tank & \\ \hline
|
|
|
|
\hline
|
|
\end{tabular}
|
|
\end{table}
|
|
}
|
|
|
|
|
|
http://www.youtube.com/watch?v=rcNeorjXMrE
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
\subsection{FMECA - Failure Modes Effects and Criticality Analysis}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMECA - Failure Modes Effects and Criticallity Analysis}
|
|
\begin{figure}
|
|
\centering
|
|
%\includegraphics[width=100pt]{./military-aircraft-desktop-computer-wallpaper-missile-launch.jpg}
|
|
\includegraphics[width=100pt]{./A10_thunderbolt.jpg}
|
|
% military-aircraft-desktop-computer-wallpaper-missile-launch.jpg: 1024x768 pixel, 300dpi, 8.67x6.50 cm, bb=0 0 246 184
|
|
\caption{A10 Thunderbolt}
|
|
\label{fig:f16missile}
|
|
\end{figure}
|
|
Emphasis on determining criticality of failure.
|
|
Applies some Bayesian statistics (probabilities of component failures and those thereby causing given system level failures).
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMECA - Failure Modes Effects and Criticality Analysis}
|
|
Very similar to PFMEA, but instead of cost, a criticality or
|
|
seriousness factor is ascribed to putative top level incidents.\pause
|
|
FMECA has three probability factors for component failures.\pause
|
|
|
|
\textbf{FMECA ${\lambda}_{p}$ value.}
|
|
This is the overall failure rate of a base component.
|
|
This will typically be the failure rate per million ($10^6$) or
|
|
billion ($10^9$) hours of operation.\pause reference MIL1991. \pause
|
|
|
|
\textbf{FMECA $\alpha$ value.}
|
|
The failure mode probability, usually denoted by $\alpha$ is the probability of
|
|
a particular failure~mode occurring within a component. \pause reference FMD-91.
|
|
%, should it fail.
|
|
%A component with N failure modes will thus have
|
|
%have an $\alpha$ value associated with each of those modes.
|
|
%As the $\alpha$ modes are probabilities, the sum of all $\alpha$ modes for a component must equal one.
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMECA - Failure Modes Effects and Criticality Analysis}
|
|
\textbf{FMECA $\beta$ value.}
|
|
The second probability factor $\beta$, is the probability that the failure mode
|
|
will cause a given system failure.\pause
|
|
This corresponds to `Bayesian' probability, given a particular
|
|
component failure mode, the probability of a given system level failure.
|
|
\pause
|
|
\textbf{FMECA `t' Value}\pause
|
|
The time that a system will be operating for, or the working life time of the product is
|
|
represented by the variable $t$.
|
|
%for probability of failure on demand studies,
|
|
%this can be the number of operating cycles or demands expected.
|
|
\pause
|
|
\textbf{Severity `s' value}
|
|
A weighting factor to indicate the seriousness of the putative system level error.
|
|
%Typical classifications are as follows:~\cite{fmd91}
|
|
\pause
|
|
\begin{equation}
|
|
C_m = {\beta} . {\alpha} . {{\lambda}_p} . {t} . {s}
|
|
\end{equation}
|
|
\pause
|
|
Highest $C_m$ values would be at the top of a `to~do' list
|
|
for a project manager.
|
|
\end{frame}
|
|
|
|
|
|
|
|
\subsection{FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
\begin{figure}
|
|
\centering
|
|
\includegraphics[width=200pt]{./SIL.png}
|
|
% SIL.jpg: 350x286 pixel, 72dpi, 12.35x10.09 cm, bb=0 0 350 286
|
|
\caption{SIL requirements}
|
|
\end{figure}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
|
|
\begin{itemize}
|
|
\pause \item \textbf{Statistical Safety} \pause Safety Integrity Level (SIL) standards (EN61508/IOC5108).
|
|
\pause \item \textbf{Diagnostics} \pause Diagnostic or self checking elements modelled
|
|
\pause \item \textbf{Complete Failure Mode Coverage} \pause All failure modes of all components must be in the model
|
|
\pause \item \textbf{Guidelines} \pause To system architectures and development processes
|
|
\end{itemize}
|
|
|
|
% FMEDA is the methodology behind statistical (safety integrity level)
|
|
% type standards (EN61508/IOC5108). \pause
|
|
% It provides a statistical overall level of safety
|
|
% and allows diagnostic mitigation for self checking etc. \pause
|
|
% It provides guidelines for the design and architecture
|
|
% of computer/software systems for the four levels of
|
|
% safety Integrity.
|
|
% %For Hardware
|
|
% \pause
|
|
% FMEDA does force the user to consider all components in a system
|
|
% by requiring that a MTTF value is assigned for each failure~mode; \pause
|
|
% the MTTF may be statistically mitigated (improved)
|
|
% if it can be shown that self-checking will detect failure modes.
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
\textbf{Failure Mode Classifications in FMEDA.}
|
|
\begin{itemize}
|
|
\pause \item \textbf{Safe or Dangerous} \pause Failure modes are classified SAFE or DANGEROUS
|
|
\pause \item \textbf{Detectable failure modes} \pause Failure modes are given the attribute DETECTABLE or UNDETECTABLE
|
|
\pause \item \textbf{Four attributes to Failure Modes} \pause All failure modes may thus be Safe Detected(SD), Safe Undetected(SU), Dangerous Detected(DD), Dangerous Undetected(DU)
|
|
\pause \item \textbf{Four statistical properties of a system} \pause \\
|
|
$ \sum \lambda_{SD}$, $\sum \lambda_{SU}$, $\sum \lambda_{DD}$, $\sum \lambda_{DU}$
|
|
\end{itemize}
|
|
|
|
% Failure modes are classified as Safe or Dangerous according
|
|
% to the putative system level failure they will cause. \pause
|
|
% The Failure modes are also classified as Detected or
|
|
% Undetected.
|
|
% This gives us four level failure mode classifications:
|
|
% Safe-Detected (SD), Safe-Undetected (SU), Dangerous-Detected (DD) or Dangerous-Undetected (DU),
|
|
% and the probabilistic failure rate of each classification
|
|
% is represented by lambda variables
|
|
% (i.e. $\lambda_{SD}$, $\lambda_{SU}$, $\lambda_{DD}$, $\lambda_{DU}$).
|
|
\end{frame}
|
|
\begin{frame}
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
\textbf{Diagnostic Coverage.}
|
|
The diagnostic coverage is simply the ratio
|
|
of the dangerous detected probabilities
|
|
against the probability of all dangerous failures,
|
|
and is normally expressed as a percentage. $\Sigma\lambda_{DD}$ represents
|
|
the percentage of dangerous detected base component failure modes, and
|
|
$\Sigma\lambda_D$ the total number of dangerous base component failure modes.
|
|
|
|
$$ DiagnosticCoverage = \Sigma\lambda_{DD} / \Sigma\lambda_D $$
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
The \textbf{diagnostic coverage} for safe failures, where $\Sigma\lambda_{SD}$ represents the percentage of
|
|
safe detected base component failure modes,
|
|
and $\Sigma\lambda_S$ the total number of safe base component failure modes,
|
|
is given as
|
|
|
|
$$ SF = \frac{\Sigma\lambda_{SD}}{\Sigma\lambda_S} $$
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
\textbf{Safe Failure Fraction.}
|
|
A key concept in FMEDA is Safe Failure Fraction (SFF).
|
|
This is the ratio of safe and dangerous detected failures
|
|
against all safe and dangerous failure probabilities.
|
|
Again this is usually expressed as a percentage.
|
|
|
|
$$ SFF = \big( \Sigma\lambda_S + \Sigma\lambda_{DD} \big) / \big( \Sigma\lambda_S + \Sigma\lambda_D \big) $$
|
|
\pause
|
|
SFF determines how proportionately fail-safe a system is, not how reliable it is ! \pause
|
|
Weakness in this philosophy; \pause adding extra safe failures (even unused ones) improves the SFF.
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
To achieve SIL levels, diagnostic coverage and SFF levels are prescribed along with
|
|
hardware architectures and software techniques. \pause
|
|
The overall the aim of SIL is classify the safety of a system,
|
|
by statistically determining how frequently it can fail dangerously.
|
|
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
{
|
|
\begin{table}[ht]
|
|
\caption{FMEA Calculations} % title of Table
|
|
%\centering % used for centering table
|
|
\begin{tabular}{|| l | l | c | c | l ||} \hline
|
|
\textbf{SIL} & \textbf{Low Demand} & \textbf{Continuous Demand} \\
|
|
& Prob of failing on demand & Prob of failure per hour \\ \hline \hline
|
|
4 & $ 10^{-5}$ to $< 10^{-4}$ & $ 10^{-9}$ to $< 10^{-8}$ \\ \hline
|
|
3 & $ 10^{-4}$ to $< 10^{-3}$ & $ 10^{-8}$ to $< 10^{-7}$ \\ \hline
|
|
2 & $ 10^{-3}$ to $< 10^{-2}$ & $ 10^{-7}$ to $< 10^{-6}$ \\ \hline
|
|
1 & $ 10^{-2}$ to $< 10^{-1}$ & $ 10^{-6}$ to $< 10^{-5}$ \\ \hline
|
|
|
|
\hline
|
|
\end{tabular}
|
|
\end{table}
|
|
}
|
|
Table adapted from EN61508-1:2001 [7.6.2.9 p33]
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{ FMEDA - Failure Modes Effects and Diagnostic Analysis}
|
|
FMEDA is a modern extension of FMEA, in that it will allow for
|
|
self checking features, and provides detailed recommendations for computer/software architecture. \pause
|
|
It has a simple final result, a Safety Integrity Level (SIL) from 1 to 4 (where 4 is safest).
|
|
|
|
%FMEA can be used as a term simple to mean Failure Mode Effects Analysis, and is
|
|
%part of product approval for many regulated products in the EU and the USA...
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
\subsection{FMEA used for Safety Critical Approvals}
|
|
|
|
\begin{frame}
|
|
\frametitle{DESIGN FMEA (DFMEA): Safety Critical Approvals FMEA}
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=100pt,keepaspectratio=true]{./tech_meeting.png}
|
|
% tech_meeting.png: 350x299 pixel, 300dpi, 2.97x2.53 cm, bb=0 0 84 72
|
|
\caption{FMEA Meeting}
|
|
\label{fig:tech_meeting}
|
|
\end{figure}
|
|
Static FMEA, Design FMEA, Approvals FMEA \pause
|
|
|
|
Experts from Approval House and Equipment Manufacturer
|
|
discuss selected component failure modes
|
|
judged to be in critical sections of the product.
|
|
|
|
|
|
|
|
\end{frame}
|
|
|
|
\begin{frame}
|
|
\frametitle{DESIGN FMEA: Safety Critical Approvals FMEA}
|
|
|
|
\begin{figure}[h]
|
|
\centering
|
|
\includegraphics[width=70pt,keepaspectratio=true]{./tech_meeting.png}
|
|
% tech_meeting.png: 350x299 pixel, 300dpi, 2.97x2.53 cm, bb=0 0 84 72
|
|
\caption{FMEA Meeting}
|
|
\label{fig:tech_meeting}
|
|
\end{figure}
|
|
|
|
\begin{itemize}
|
|
\pause \item Impossible to look at all component failures let alone apply FMEA rigorously.
|
|
\pause \item In practise, failure scenarios for critical sections are contested, and either justified or extra safety measures implemented.
|
|
\pause \item Often Meeting notes or minutes only. Unusual for detailed arguments to be documented.
|
|
\end{itemize}
|
|
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
Addendum --- reasoning distance
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
Note here that we have had to look at the failure~mode
|
|
in relation to the entire circuit. \pause
|
|
We have used intuition to determine the probable
|
|
effect of this failure mode. \pause
|
|
We have not examined this failure mode
|
|
against every other component in the system. \pause
|
|
Perhaps we should.... this would be a more rigorous and complete
|
|
approach in looking for system failures.
|
|
|
|
\end{frame}
|
|
|
|
\subsection{Rigorous FMEA - State Explosion}
|
|
\begin{frame}
|
|
\frametitle{Rigorous Single Failure FMEA}
|
|
Consider the analysis
|
|
where we look at all the failure modes in a system, and then
|
|
see how they can affect all other components within it.
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{Rigorous Single Failure FMEA}
|
|
We need to look at a large number of failure scenarios
|
|
to do this completely (all failure modes against all components).
|
|
This is represented in the equation below. %~\ref{eqn:fmea_state_exp},
|
|
where $N$ is the total number of components in the system, and
|
|
$f$ is the number of failure modes per component.
|
|
|
|
|
|
\begin{equation}
|
|
\label{eqn:fmea_single}
|
|
N.(N-1).f % \\
|
|
%(N^2 - N).f
|
|
\end{equation}
|
|
\end{frame}
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{Rigorous Single Failure FMEA}
|
|
This would mean an order of $N^2$ number of checks to perform
|
|
to undertake a `rigorous~FMEA'. Even small systems have typically
|
|
100 components, and they typically have 3 or more failure modes each.
|
|
$100*99*3=29,700$.
|
|
\pause
|
|
The European Gas burner standard (EN298:2003), demands the checking of
|
|
double failure scenarios (for burner lock-out scenarios).
|
|
\end{frame}
|
|
|
|
|
|
|
|
|
|
\begin{frame}
|
|
\frametitle{Rigorous Double Failure FMEA}
|
|
For looking at potential double failure scenarios (two components
|
|
failing within a given time frame) and the order becomes
|
|
$N^3$. \pause
|
|
|
|
\begin{equation}
|
|
\label{eqn:fmea_double}
|
|
N.(N-1).(N-2).f % \\
|
|
%(N^2 - N).f
|
|
\end{equation}
|
|
\pause
|
|
$100*99*98*3=2,910,600$.
|
|
\pause
|
|
|
|
.\\
|
|
\end{frame}
|
|
\end{document}
|