Well got stuck into the presentation there,
started on the software example
This commit is contained in:
parent
0e5d8368ec
commit
01bf8de1fd
@ -8,16 +8,36 @@
|
||||
\setbeamertemplate{footline}[page number]
|
||||
|
||||
|
||||
\newcommand{\fg}{\em functional~group}
|
||||
\newcommand{\fgs}{\em functional~groups}
|
||||
%\newcommand{\fg}{\em functional~group}
|
||||
%\newcommand{\fgs}{\em functional~groups}
|
||||
\newcommand{\fg}{\em functional~grouping}
|
||||
\newcommand{\fgs}{\em functional~groupings}
|
||||
\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{\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 (re-use 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}
|
||||
@ -28,9 +48,9 @@
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{FMEA}
|
||||
This talk introduces Failure Mode Effects Analysis, and the different ways it is applied.
|
||||
We now talk about Failure Mode Effects Analysis, and the different ways it is applied.
|
||||
These techniques are discussed, and then
|
||||
a refinement is proposed, which is essentially a modularisation of the FMEA process.
|
||||
a refinement(FMMD) is proposed, which is essentially a modularisation of the FMEA process.
|
||||
%
|
||||
|
||||
\begin{itemize}
|
||||
@ -654,8 +674,8 @@ judged to be in critical sections of the product.
|
||||
\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 $ \bowtie $ to represet it.
|
||||
\pause $ \bowtie ( FunctionalGroup ) \rightarrow {DerivedComponent} $
|
||||
%\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}
|
||||
@ -914,7 +934,7 @@ with equation~\ref{eqn:anscen}.
|
||||
% and equation~\ref{eqn:anscen}.
|
||||
% \clearpage
|
||||
|
||||
%\section{Example}/bowtie
|
||||
%\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.
|
||||
@ -1024,7 +1044,7 @@ missed in an analysis.
|
||||
|
||||
|
||||
|
||||
\subsection{conclusion}
|
||||
\subsection{FMMD summary}
|
||||
\begin{frame}
|
||||
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
||||
\textbf{Conclusion: FMMD}
|
||||
@ -1037,9 +1057,133 @@ missed in an analysis.
|
||||
\end{itemize}
|
||||
\end{frame}
|
||||
|
||||
\section{Software and Failure Mode Effects Analysis}
|
||||
|
||||
\subsection{Software and FMEA---Current work}
|
||||
\begin{frame}
|
||||
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
||||
\textbf{Questions?}
|
||||
\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 considers all variables within a function as potentially corruptible ---
|
||||
\pause this means a large number of combinations --- databases
|
||||
to track the relationships between variables
|
||||
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
|
||||
\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.
|
||||
\end{frame}
|
||||
|
||||
\begin{frame}
|
||||
\frametitle{FMMD - How to apply this to software}
|
||||
\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 \pause these can correspond to failure modes
|
||||
and symptoms of failure for the function
|
||||
\pause \item We can apply contract programming, giving a function pre and post conditions
|
||||
\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
|
||||
\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.
|
||||
|
||||
Yourdon, afferent---transform---efferent data flow, in an embedded system our
|
||||
sensors---data processing/software---actuators.
|
||||
So the electronics are the bottom.
|
||||
|
||||
Starting with the bottom-up for this {\ft} input, we have the resistor
|
||||
|
||||
\end{frame}
|
||||
|
||||
\end{document}
|
||||
|
BIN
presentations/System_safety_2012/ftcontext.png
Normal file
BIN
presentations/System_safety_2012/ftcontext.png
Normal file
Binary file not shown.
After Width: | Height: | Size: 24 KiB |
Loading…
Reference in New Issue
Block a user