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]
|
\setbeamertemplate{footline}[page number]
|
||||||
|
|
||||||
|
|
||||||
\newcommand{\fg}{\em functional~group}
|
%\newcommand{\fg}{\em functional~group}
|
||||||
\newcommand{\fgs}{\em functional~groups}
|
%\newcommand{\fgs}{\em functional~groups}
|
||||||
|
\newcommand{\fg}{\em functional~grouping}
|
||||||
|
\newcommand{\fgs}{\em functional~groupings}
|
||||||
\newcommand{\dc}{\em derived~component}
|
\newcommand{\dc}{\em derived~component}
|
||||||
\newcommand{\dcs}{\em derived~components}
|
\newcommand{\dcs}{\em derived~components}
|
||||||
\newcommand{\bc}{\em base~component}
|
\newcommand{\bc}{\em base~component}
|
||||||
\newcommand{\bcs}{\em base~components}
|
\newcommand{\bcs}{\em base~components}
|
||||||
\newcommand{\irl}{in~real~life}
|
\newcommand{\irl}{in~real~life}
|
||||||
|
\newcommand{\derivec}{\ensuremath{\mathcal{\bowtie}}}
|
||||||
|
\newcommand{\ft}{\ensuremath{4\!\!\rightarrow\!\!20mA} }
|
||||||
\begin{document}
|
\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.}
|
\section{F.M.E.A.}
|
||||||
\begin{frame}
|
\begin{frame}
|
||||||
\frametitle{FMEA}
|
\frametitle{FMEA}
|
||||||
@ -28,9 +48,9 @@
|
|||||||
|
|
||||||
\begin{frame}
|
\begin{frame}
|
||||||
\frametitle{FMEA}
|
\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
|
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}
|
\begin{itemize}
|
||||||
@ -654,8 +674,8 @@ judged to be in critical sections of the product.
|
|||||||
\pause \item Collect Symptoms.
|
\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 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 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 \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 $ \bowtie ( FunctionalGroup ) \rightarrow {DerivedComponent} $
|
\pause $ \derivec ( FunctionalGroup ) \rightarrow {DerivedComponent} $
|
||||||
%\item could use AMALG instead here $ \amalg $
|
%\item could use AMALG instead here $ \amalg $
|
||||||
\end{itemize}
|
\end{itemize}
|
||||||
\end{frame}
|
\end{frame}
|
||||||
@ -914,7 +934,7 @@ with equation~\ref{eqn:anscen}.
|
|||||||
% and equation~\ref{eqn:anscen}.
|
% and equation~\ref{eqn:anscen}.
|
||||||
% \clearpage
|
% \clearpage
|
||||||
|
|
||||||
%\section{Example}/bowtie
|
%\section{Example}/derivec
|
||||||
\begin{frame}
|
\begin{frame}
|
||||||
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
||||||
To see the effects of reducing `state~explosion' we can use an example.
|
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}
|
\begin{frame}
|
||||||
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
||||||
\textbf{Conclusion: FMMD}
|
\textbf{Conclusion: FMMD}
|
||||||
@ -1037,9 +1057,133 @@ missed in an analysis.
|
|||||||
\end{itemize}
|
\end{itemize}
|
||||||
\end{frame}
|
\end{frame}
|
||||||
|
|
||||||
|
\section{Software and Failure Mode Effects Analysis}
|
||||||
|
|
||||||
|
\subsection{Software and FMEA---Current work}
|
||||||
\begin{frame}
|
\begin{frame}
|
||||||
\frametitle{FMMD - Failure Mode Modular De-Composition}
|
\frametitle{Software FMEA (SFMEA) --- Current work }
|
||||||
\textbf{Questions?}
|
%\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{frame}
|
||||||
|
|
||||||
\end{document}
|
\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