OK good bash at it.... better cycle home...

papers/fmmd_software_hardware/software_fmmd.tex

@@ -885,17 +885,20 @@ We now analyse this hardware/software combined {\fg}.
      2: ${VREF}$          &  ADC volt-ref         &    $VV\_ERR$          \\ 
                              &  incorrect         &                   \\    \hline   
 
+%%% FORGOT THAT ONE !!!!! 04OCT2012 %%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
+      3: ${ADC\_TIMEOUT}$          &  ADC volt-ref         &    $VV\_ERR$          \\ 
+                             &  incorrect         &                   \\    \hline   
+%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
 
- 
-     3: $CMATV_{V\_ERR}$      &  voltage value     &      $VV\_ERR$          \\   
+     4: $CMATV_{V\_ERR}$      &  voltage value     &      $VV\_ERR$          \\   
                              &  incorrect          &                 \\ \hline 
 
 
 
-     4: $CMATV_{HIGH}$        & ADC may read      &         $HIGH$           \\  
+     5: $CMATV_{HIGH}$        & ADC may read      &         $HIGH$           \\  
                                &   wrong channel  &                  \\ \hline 
 
-     5: $CMATV_{LOW}$        &  output low   &       $LOW$              \\  \hline     
+     6: $CMATV_{LOW}$        &  output low   &       $LOW$              \\  \hline     
     
 \hline
 

presentations/System_safety_2012/Makefile

@@ -1,5 +1,5 @@
 
-DIAPNG= three_tree.png component.png  fmmd_env_op_uml.png  fmmd_exm_h.png  master_uml.png  mvampcircuit.png  mvamp.png  n_inv_dc.png  pd.png  pd_euler2.png  pd_euler.png
+DIAPNG= three_tree.png component.png  fmmd_env_op_uml.png  fmmd_exm_h.png  master_uml.png  mvampcircuit.png  mvamp.png  n_inv_dc.png  pd.png  pd_euler2.png  pd_euler.png contract_function.png hd.png
 
 %.png:%.dia
 	dia -t png $<

presentations/System_safety_2012/fmmd_software_pres.tex

@@ -12,12 +12,15 @@
 %\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{\mathcal{\bowtie}}}
+\newcommand{\derivec}{\ensuremath{{D}}}
 \newcommand{\ft}{\ensuremath{4\!\!\rightarrow\!\!20mA} }
 \begin{document}
 
@@ -29,7 +32,7 @@
 \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 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}
@@ -205,7 +208,7 @@ double failure scenarios (for burner lock-out scenarios).
 \frametitle{Four main Variants of FMEA}
  \begin{itemize}
  \pause \item \textbf{PFMEA - Production}  \pause Car Manufacture etc
-   \pause \item \textbf{FMECA - Criticallity}  \pause Military/Space
+   \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}
@@ -1050,7 +1053,7 @@ missed in an analysis.
 \textbf{Conclusion: FMMD}
 
 \begin{itemize}
-  \pause \item Addresses State Explosion
+  \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
@@ -1065,14 +1068,16 @@ missed in an analysis.
  %\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 
+  \pause \item SFMEA maps variable corruption for {\fms} ---
+  \pause this means a large number of combinations ---  \pause automated SFMEA 
+  \pause databases
+  \pause 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 %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
@@ -1095,22 +1100,57 @@ and system failure modes
 \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 \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 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 \item Post condition violations are analogous to symptoms of failure of the function \pause derived component failure modes
 \end{itemize}
 
 \end{frame}
@@ -1173,17 +1213,440 @@ General Failure behaviour of {\ft} signalling
 % 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.
  So the electronics are the bottom.
  
- Starting with the bottom-up for this {\ft} input, we have the resistor
  
 \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, $ fm(Read\_ADC) = \{ CHAN\_NO, VREF \} $ which is called by
+$ fm(read\_4\_20\_input) = \{ VRNGE \} .$ \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=120pt]{./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=160pt]{./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.
+
+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 \item Additionally, using FMMD we can determine a failure model for the hardware/software interface~\cite{sfmeainterface}.
+\end{itemize}
+
+
+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}
+
+
+
+
+
+
+
 \end{document}