6b424cb9fc
who requested it. fmmd_software_pres_pc --- fmmd_software_pres_pc where `pc' means post conference.
1178 lines
37 KiB
TeX
1178 lines
37 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]
|
|
|
|
|
|
%%% THIS VERSION IS FOR SENDING TO DELEGATES WHO REQUESTED THE PRESENTATION
|
|
%%% TD 18OCT2012
|
|
%%%
|
|
|
|
%\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 FMMD seamlessly integrates mechanical, electronics and software failure models.
|
|
\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 ?
|
|
\end{frame}
|
|
|
|
|
|
\end{document}
|